Native App vs Web App

Native App 이란?

• Native는 말 그대로 각 OS에 맞추어 개발하는 방식임
• 예를 들면, 갤럭시 폰은 Android 운영체제이고, iPhone은 iOS 운영체제인데
  Andorid의 경우 Java, Kotlin등을 사용하고
  iPhone의 경우 Object-C, Swift등을 사용하여 개발을 말함
• 실제로 우리가 앱마켓(Android: 구글플레이어, iOS: App)에서 다운로드 받는 App을 말함

Web App 이란?

• 각 운영체제별(Android, iOS) 스토어 업로드가 안됨
• 즉, 스토어에서 직접 다운로드 하는 방식이 아닌 폰에서 웹사이트를 통해 접속하는 방식임
• 폰으로 접속하여 웹페이지에서도 모바일 최적화 사이트를 볼 수 있는 장점이 있음

적응형 vs 반응형

반응형 웹

• 하나의 템플릿으로 모바일, 태블릿, 데스크탑 모든 기기에 대응할 수 있는 웹
• 마크업 작업을 할 때 고정된 px값이 아닌 em, rem, % 처럼 백분율 값으로 작업해야 함
• 하나의 템플릿으로 만드는 작업이라 미디어쿼리(Media Query)를 사용해서 해상도 디바이스 등 특정 화면에 따라 레이아웃을 변경

적응형 웹

• 모바일용, 데스크탑 등 각각의 디바이스 별로 독립적인 템플릿을 만들고, 각각의 디바이스에 맞는 페이지를 별도 제작 후 랜딩되는 웹
• pc로 접속했을 때, naver.com으로 랜딩되고, mobile로 접속했을 때, m.naver.com으로 랜딩됨.

장단점

반응형:

1. 웹사이트에서 쓰이는 모든 쿤텐츠를 다운받은 후 현재 해상도에 맞는 화면 랜딩됨
2. mobile로 접속해도 pc와 mobile 모든 리소스를 다운받음
3. 모든 리소스를 다운받아 로딩 속도가 느림

적응형:

1. 감지된 디바이스에 맞는 필요한 콘텐츠만 다운 받은 후 화면 랜딩됨
2. mobile로 접속하면 pc는 다운받지 않고 mobile 리소스만 다운받음
3. 필요한 컨텐츠만 다운받아 로딩 속도가 빠름
   

쿠키 vs 세션 vs 캐시

쿠키란?

• 쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일임.
• 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있음
• 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조함
• 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장됨
• Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있음.
• 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송함.
• 쿠키 사용 예): 아이디 로그인 저장, 쇼핑몰의 장바구니, 자동로그인 팝업에서 "오늘 더 이상 보지 않음" 체크

세션이란?

• 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠기와 달리 세션은 서버 측에서 관리함

• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지

• 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능함.

• 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 됨.

• 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 됨

• 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는데 이것이 세션ID임.

• 세션 사용 예): 로그인 같이 보안상 중요한 작업을 수행할 때 사용

차이 비교

• 가장 큰 차이점은 사용자의 정보가 저장되는 위치임. 쿠키: 브라우저 스토리지, 세션: 서버
• 보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 빠름. 세션은 서버 처리가 필요하기 때문.
• 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이요해서 sessionid만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋음.
• 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됨

정리

• 세션은 사용자의 수 만큼 서버 메모리를 차지하기 때문에, 최근에는 이런 문제들을 보완한 토큰 기반의 인증방식을 사용하는 추세임.(JWT)

캐시

• 캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것임
• 한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있다.
• 보통 쿠키와 세션의 차이를 물어볼 때 저장위치와 보안에 대해서는 잘 말하는데 사실 중요한 것은 라이프사이클을 얘기하는 것임.

요약

• 쿠키는 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일
• 세션은 쿠키랑 같지만 저장되는 위치가 서로 다르다 쿠키는 로컬, 세션은 서버
• 캐시는 불필요한 데이터 전송을 줄이기 위해서 캐시라는 저장공간에 데이터를 저장해두고 사용하는 것

API

API란?

• 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 뜻함.

SOAP(Simple Object Access Protocol)

• SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신함.
• SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있음.

REST(Representational State Transfer)

• REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라고 함.
• SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며, 따라서 RESTful 웹 API에는 공식적인 표준이 없음.
• RESTful 시스템의 다음 6가지 주요 제약 조건을 준수 했을 때 RESTful API라고 간주 할 수 있음.

1. 클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리함
2. 스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됨.
3. 캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있음.
4. 계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있음.
5. 코드 온디맨드(옵션): 서버에서 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있음
6. 통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함함
   A. 요청에서 리소스 식별
   B. 표현을 통한 리소스 조작
   C. 자기 기술적 메시지
   D. 애플리케이션 상태 엔진으로서의 하이퍼미디어

또 다른 API표준은 쿼리 언어이자 서버측 런타임으로 REST의 대안인 GraphQL임.
GraphQL은 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선순위를 둠.
REST를 대체할 수 있는 GraphQL은 개발자가 단일 API호출로 다양한 데이터 소스에서 데이터를 끌어오는 요청을 구성할 수 있도록 지원함.