정의 : 

동기적(Synchronous)

- 특정 코드를 수행 완료한 이후 아래줄의 코드 수행

- 즉 지금 진행하는 작업이 끝이나면 다른 작업으로 넘어가고 그 작업이 끝이 나면 다른 작업으로 넘어가는 방식이 동기적 처리 방식이라고 한다.

비동기적(Asynchronous)

- 특정 코드를 수행하는 도중에도 아래로 계속 내려가며 수행함

- 순서대로 진행하는 것일 아니라 한번에 여러개가 진행되는 것과 마찬가지다. 비동기적 처리는 주로 api요청, 파일읽기, 암호화, 복호화 등에서 자주 사용된다.

특징 : 

동기 : 

속도가 느림

진행방향이 일방향이기 때문에 코드에서 에러가 나면, 어디인지 파악하기 쉬움

비동기 :  

속도가 동기에 비해 빠름

언어 : 

동기적 언어 - Argos, Atom 등의 대부분 모르는 언어들

비동기적 언어 - Java, C++, Python, JavaScript 등

주의할 점 : 

혼동하지 말아야 할 것이, 동기/비동기적 실행은 멀티 스레딩과 전혀 관련이 없다. 즉 하나의 스레드에서도 비동기적 실행을 할 수 있고, 멀티 스레드에서도 동기적 실행을 할 수 있다. 스레드 혹은 코어의 개수가 중요한 것이 아니라, 서브루틴간의 실행 순서가 정해져 있는지가 중요하다. 이와 관해선, 이 링크의 그림을 참고하자.

참고 : 

https://wakestand.tistory.com/235

https://velog.io/@hyundong_kk/%EB%8F%99%EA%B8%B0%EC%A0%81-vs-%EB%B9%84%EB%8F%99%EA%B8%B0%EC%A0%81

https://code-masterjung.tistory.com/69

RDBMS

장점 : 

업무 변화에 대한 적응력이 높아 변화하는 업무에 쉽게 활용하며 유지보수가 편리하다. 따라 생산성도 향상된다. 명확하게 스키마가 정의되어 있다. 데이터 무결성을 보장한다.

단점 :

다른 DBMS보다 더 많은 자원이 활용되어 시스템의 부하가 높다.

NoSQL (Not Only SQL)

특징 : 

관련이 없는 데이터들의 집합으로 만든다. 데이터를 구조적으로 정의하기 힘들거나 쉽지않는 경우 사용한다. 예로는 로그라던가 인공지능 데이터, 검색 데이터 결과 등 규칙이 없는 데이터가 대표적이다.

NoSQL은 RDB의 특성 뿐만 아니라 다른 특성까지도 지원해 주는 데이터베이스라는 의미를 지닌다.

장점 :

스키마가 없기에 유연하게 작성 가능. 데이터가 애플리케이션이 필요로하는 형태로 저장되어 읽는 속도가 빠르다.

대용량 데이터를 다루거나 데이터 분산 처리에 용이. 유연한 데이터 모델링이 가능. Cloud Computing에 적합.

단점 :

유연성으로인한, 데이터 구조 결정이 늦춰질 수 있음. 데이터가 여러 컬렉션에 중복되어있어, 수정(Update)해야하는 경우 모든 컬렉션에서 수행하여야함.

MVC 패턴

MVC는 패턴은 애플리케이션을 세가지영역 ,

모델 뷰 컨트롤러 구분하여 작업을 분리함으로 서로간의 결합도를 최소화 하고 유지보수성도 높이며

개발자들이 각각 맡은 영역에만 집중하게 하여 개발의 효율성을 극대화 할수 있는 장점이 있다.

[1]뷰(View)

클라이언트가 보는 화면 요청이 일어나가 처리된 결과를 보여주는 페이지

[2] 컨트롤러(Controller)

컨트롤러는뷰에서 클라이언트가 서비스를 요청 했을때 실행되는 페이지이다.

컨트롤러는 다음과 같은 기능을 처리

1. 뷰에서 들어온 요청을 받음
2. 클라이언트가 전달한 파라미터를 추출
3. 파라미터 유효성 검사 실패하면 뷰로 이동
4. 서비스  객체의 메소드를 호출하여 파라미터 서비스 객체로 전달
5. 출력 뷰 페이지로 이동.

[3] 모델 (Model)

두가지 가 있다 서비스처리를 담당하는 Service 다른 하나는 데이터베이스 처리를 담당하는  DAO 객체

**Model**은 어플리케이션이 “무엇”을 할 것인지를 정의 합니다. 내부 비지니스 로직을 처리하기 위한 역할을 할 것입니다.

• 처리되는 알고리즘, DB 와 상호작용(CRUD Create Read Update Delete), 데이터 등등..

**Controller**는 모델이 “어떻게” 처리할 지를 알려주는 역할을 할 것이고, 모바일에서는 화면의 로직처리 부분입니다. 화면에서 사용자의 요청을 받아서 처리되는 부분을 구현되게 되며, 요청 내용을 분석해서 Model과 View에 업데이트 요청을 하게 됩니다.

• 사용자로 부터의 입력 을 받고 Model 또는 View중개인 역할

**View**는 화면에 “무엇” 인가를 “**보여주기 위한 역할”**을 합니다. 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것입니다.

MVP 패턴

MVP 모델은 Model-View-Presenter 로 구성됩니다. 

■ 뷰(View)

The view is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.
실제 view 에 대한 직접적인 접근을 담당합니다. 안드로이드에서 액티비티/프래그먼트는 뷰의 일부로 정의합니다.  
View 에서 발생하는 이벤트는 직접 핸들링 할 수 있으나 Presenter 에 위임하도록 합니다. 위임하는 방법은 액티비티가 뷰 인터페이스를 구현해서 Presenter에서 코드를 만들 인터페이스를 갖도록 하면 됩니다. 이렇게 하면 특정 뷰와 결합되지 않고 가상 뷰를 구현해서 간단한 유닛 테스트를 실행할 수 있습니다. 

■ 프리젠터(Presenter)

The presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view
본질적으로는 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 인터페이스로 연결된다는 점이 다릅니다. 이에 따라 MVC가 가진 테스트 가능성 문제와 함께 모듈화/유연성 문제 역시 해결합니다. 프리젠터(Presenter)의 역할을 한줄로 표현한다면 뷰(View)와 모델(Model) 사이에서 자료 전달 역할을 합니다. 

■ 모델(Model)

The model is an interface defining the data to be displayed or otherwise acted upon in the user interface.
앱 데이터 및 상태에 대한 비지니스 로직을 수행합니다.

차이점

추가로 MVC와의 차이점을 더 설명하자면, 액티비티와 프래그먼트가 이제 View의 일부로 간주된다는 점입니다. 그렇기 때문에 View는 유저 액션 이벤트를 Presenter로 전달하는 역할을 합니다.

Presenter는 Model과 View의 가운데서 상호작용 관리를 하며 내용상 MVC의 컨트롤러와 동일하지만 View에 연결되지 않는 단순 인터페이스라는 점에서 차이가 있습니다.

그렇기 때문에 View에게 표시할 방법을 지시하지 않고 단순히 UI에 표시할 내용(Data)만 View에게 전달하게 됩니다.

그리고 이 내용(Data)을 기반으로 View는 스스로 UI를 업데이트를 합니다.

출처: 

https://faith-developer.tistory.com/71

프로젝트 버전 관리 툴

프로젝트를 진행하게 되면 단순히 자신이 작성한 코드만으로 개발하는 것이 아니라 많은 라이브러리들을 활용해서 개발을 하게 된다. 이 때 사용되는 라이브러리들의 수가 수십개가 훌쩍 넘어버리는 일이 발생해 이 많은 라이브러리들을 관리하는 것이 힘들어지는 경우가 종종 발생하곤 한다. Maven은 이러한 문제를 해결해 줄수 있는 도구이다. Maven은 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데 필요한 다른 라이브러리들까지 관리하여 네트워크를 통해 자동으로 다운 받아준다.

비교 

Maven같은경우는 스프링프로젝트에서 pom.xml이란 이름으로 쓰고,

Gradle은 스프링부트, 안드로이드에서 쓰는걸로 알고있다.

Maven

Maven은 프로젝트의 전체적인 라이프사이클을 관리하는 도구이며, 많은 편리함과 이점이 있어 널리 사용되고 있다. 기존에는 Ant가 많이 사용되었지만 Maven이 Ant를 넘어서 더 많은 개발자들이 사용하게 되었고 비교적 최근에는 Gradle이 새롭게 나와 사용되고 있다.

Gradle

Gradle이란 기본적으로 빌드 배포 도구(Build Tool)이다. 안드로이드 앱을 만들때 필요한 공식 빌드시스템이기도 하며 JAVA, C/C++, Python 등을 지원한다.

그래서 무엇을 사용하면 좋을까? with toy project

지금 시점에서 Gradle을 사용하지 않을 이유는 익숙함 뿐인 것 같다.

Gradle이 출시되었을 때는 Maven이 지원하는 Scope를 지원하지 않았고 성능면에서도 앞설것이 없었다.

Ant의 유연한 구조적 장점과 Maven의 편리한 의존성 관리 기능을 합쳐놓은 것만으로도 많은 인기를 얻었던 Gradle은 버전이 올라가며 성능이라는 장점까지 더해지면서 대세가 되었다.

장점 :

• Build라는 동적인 요소를 XML의 정의하기에 따른 어려움
• Groovy를 사용함으로써, 동적인 빌드 호출에 용이함. 즉 빌드시간이 훨씬 단축
• concurrent에 안전한 캐시 사용

참조 :

https://jisooo.tistory.com/entry/Spring-%EB%B9%8C%EB%93%9C-%EA%B4%80%EB%A6%AC-%EB%8F%84%EA%B5%AC-Maven%EA%B3%BC-Gradle-%EB%B9%84%EA%B5%90%ED%95%98%EA%B8%B0

https://hyojun123.github.io/2019/04/18/gradleAndMaven/

https://100100e.tistory.com/249

https://okky.tistory.com/179

서버 애플리케이션 플랫폼의 큰 두 축은 Spring Boot와 Node.js이다.

Node.js

-특징

Node js는 Non-blocking I/O를 처리하는데 최적화된 플랫폼이다.

Non-blocking I/O는 다른 작업이 처리되는 걸 기다리는 도중에 다른 작업을 하는 것을 말하며 짧은 시간에 여러 작업을 처리할 수 있어 효율적이다.

다른 언어에서도 이런 형태로 구현은 가능하지만 코드가 너무 지저분해지고 구현이 어려운 단점이 있었는데 Node js에서는 비동기식 함수를 통해 코드 상에서 이 작업을 구현하기 간편하게 만들어줬다.

실제로 최근에 만든 사이드프로젝트에서 Non-blocking I/O를 구현하는게 정말 간편했다. 그리고 내부적으로는 하나의 Thread를 이용해서 구현했기 때문에 메모리를 크게 잡아 먹지도 않아 효율적이다. 똑같은 애플리케이션을 돌려도 다른 프레임워크보다 Node.js가 소모하는 메모리의 크기가 적다.

-단점

JavaScript 언어를 사용한다는 점이다.

JavaScript가 배우기는 참 쉬워서 적은 시간을 투자하고 금방 숙달을 할 수 있으나 프로젝트 규모가 커지면 커질수록 Type Safe 하지 못하는 점이 한계점으로 작용한다.

언어가 Type Safe 하지 못하면 내가 짠 코드가 별것도 아닌 에러로 런타임에 죽을 수도 있다.

대부분 이 에러는 Java나 C언어 를 사용했다면 빌드 중에 발생하는 컴파일 에러 종류인데 JavaScript는 빌드하는 과정이 없기 때문에 실행 전에 잡아 주질 못한다.

또한 SingleThread이다.

구현하고 서버 실행까지 매우 빠르다고 좋아 할지 모르나 이 사이에 컴파일 오류는 없을 지 꼼꼼히 봐야한다.

그리고 Type Safe하지 못해서 IDE에서 자동 완성이 잘 되지 않는다.

프로젝트가 커지면 커질수록 리팩토링을 하거나 기존 코드를 써먹어서 확장해야 할 때 자동완성 기능이 핵심인데 JavaScript를 쓰면 자동완성이 잘 안돼서 큰 애를 먹게 된다.

프론트엔드 프레임워크 React에서는 TypeScript를 도입해서 어느정도 보완하고 있는데 Node.js에서도 TypeScript를 도입하는 시도가 있다고 들었는데 어느 정도 진행됐는지 모르겠다. 

Spring Boot

-특징

Java로 만든 서버 애플리케이션이다.

Java를 개발해본 사람들은 쉽게 Spring Boot에 적응 할 수 있다.

역사가 오래 됐기 때문에 개발하는데 필요한 왠만한 라이브러리는 모두 Spring Boot에 다 있다.

안드로이드 개발자가 사용한 자바 라이브러리들은 모두 Spring에서도 찾을 수 있다고 볼 수 있고 추가로 서버 개발자들이 어려움을 겪는 데이터베이스 관리도 스프링부트에서는 JPA라는 라이브러리를 통해 간소화 해둬서 손쉽게 다룰 수 있다.

그리고 Java이기 때문에 TypeSafe 하다. 

리팩토링하거나 확장 할 때 IDE를 이용해서 수정할 점을 빠르게 체크 할 수 있는데 프로젝트 규모가 커지고 안정성이 중요해지는 시점부터는 큰 장점으로 다가온다.

내부적으로는 Multi Threading을 지원하는 구조로 짜여있어서 길고 반복적인 업무를 처리할 때 효율적이다. 많은 양의 컴퓨팅이 필요한 경우 잘 써먹으면 좋다.

-단점

한번 써보신 분들은 알겠지만 Spring Boot는 러닝 커브가 존재한다.

Node.js는 처음 배우는 사람도 하루만에 서버 구동하고 api도 하나 만들 수 있는데 Spring Boot를 공부하면 Service, Controller, Repository 에 대해서 알아야하고 각 컴포넌트는 어떤식으로 채워야하는지 공부가 필요해 해야 할 게 많다.

Spring Boot에서는 좋은 구조를 유도하기 위해 이런 형태의 디자인을 권장하는데 초심자한테는 러닝 커브가 좀 있다.

그리고 boilerplate 코드가 많다. 스프링에서 권장하는 구조랑 라이브러리들을 사용하려면 이런 저런 코드를 만들어야 하는데 처음에는 어려우나 숙달되면 귀찮아진다.

그래도 안쓰는 것 보다 낫긴 하지만. 내부적으로는 메모리를 좀 많이 쓴다.

Multi thread 환경이기 때문에 여러개의 Thread를 띄우다 보니까 어쩔 수 없이 생긴 문제인 것 같다. 

비교 

언제 어떤기술을 사용하는게 유리할까?

Cpu Intensive

cpu intensive한 작업이 많은 경우 Node.js가 불리(모든 req를 main thread로 처리하는데, cpu-intensive작업의 경우 딥러닝, 데이터분석, 머신러닝 등 main thread를 잠깐 멈추게 함)
io 작업이 아니라 cpu를 많이 사용하도록 작성된 함수가 있는데 어떤 요청이 들어와서 이 함수를 사용한다고 가정해보자. 해당 코드는 libuv에 있는 스레드풀로 던겨저서 요청을 비동기방식으로 처리하지 않고 이벤트 루프 자체에서 blocking 당하고 작업이 끝날때 까지 다른 요청들은 계속해서 쌓이게 되면서 성능이 저하된다.

Concurency

채팅 서비스의 경우 동시에 엄청난 클라이언트 요청이 발생할 수 있다.
일반적인 채팅서비스에는 단순하게 텍스트 메시지만 주고 받는데 여기서 Node.js를 사용하게 되면 유리하다.

Object DB의 API서버

mongoDB와 같은 JSON기반 DB를 사용하는 경우 Java를 선택하면 JSON데이터를 읽어오고 쓸때 JSON변환과정이 생기게 된다.
Nodejs를 사용하면 JSON을 별도의 변환없이 바로 사용할수 있어 훨씬 유리하다.

Node.js가 조흔 상황

1. 다중처리를 동시에 처리하도록 요구된다.
2. 많은 I/O작업을 수행한다.
3. 단순한 CPU작업만을 진행한다.

이같은 전제사항은 오늘날 전형적인 웹 애플리케이션의 특징이다. 따라서 Node.js가 spring에 비해 성능상 우위라고 거론되는 이유는 Node.js가 이러한 '전형적인' 웹 애플리케이션의 요구사항과 잘 어우러지기 때문이라고 할 수 있다.
(반대로 만하면 I/O작업이 많지 않고 강도 높은 CPU연산이 요구된다면 한개의 Thread를 사용하는 Node.js는 급격한 성능 저하가 야기된다.)

출처: 

https://winteri-i.tistory.com/48

https://velog.io/@syi9595/nodejsexpress-vs-springboot

https://selfish-developer.com/entry/Nodejs-vs-Spring-Boot

Spring

정의

자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크, 동적인 웹 사이트를 개발할때 주로 쓰임

밑의 3가지 특징들로 인해서 좀더 결합도를 낮추는 방식으로 어플리케이션을 개발할 수 있습니다.

이러한 개발방식으로 개발한 응용프로그램은 단위테스트가 용이하기 때문에 보다 퀄리티 높은 프로그램을 개발할 수 있습니다.

특징 : 

제어의 역전(IOC)

의존성 주입(DI)

관점 지향 프로그래밍(AOP)

Spring Boot

Spring은 환경설정이 복잡한 편이다. 이에 어려움을 느끼는 사용자들을 위해 나온 것이 바로 스프링 부트다.

스프링 부트는 스프링 프레임워크를 사용하기 위한 설정의 많은 부분을 자동화하여 사용자가 정말 편하게 스프링을 활용할 수 있도록 돕는다.

스프링 부트 starter 디펜던시만 추가해주면 바로 API를 정의하고, 내장된 탐캣이나 제티로 웹 애플리케이션 서버를 실행할 수 있다. + 심지어 스프링 홈페이지의 이니셜라이저를 사용하면 바로 실행 가능한 코드를 만들어준다.

실행환경이나 의존성 관리 등의 인프라 관련 등은 신경쓸 필요 없이 바로 코딩을 시작하면 된다.

그리고 바로 그것이 스프링의 키 포인트이다.

한번 스타터 Dependency를 추가하면 스프링부트 스타터 웹프로젝트가 pre-packaged된 형태로 제공됩니다.

그로인해 개발자는 Dependency 관리와 호환버전에 대하여 고려할 필요가 없습니다.

1.

스프링부트는 자동설정(AutoConfiguration)을 이용하였고 어플리케이션 개발에 필요한 모든 내부 디펜던시를 관리합니다. 개발자가 해야하는건 단지 어플리케이션을 실행할 뿐입니다. 스프링의 jar파일이 클래스 패스에 있는 경우 Spring Boot는 Dispatcher Servlet으로 자동 구성합니다. 마찬가지로 만약 Hibernate의 jar파일이 클래스 패스내에 존재한다면 이를 datasource로 자동설정하게 됩니다. 스프링부트는 미리설정된 스타터 프로젝트를 제공합니다.

2.

웹어플리케이션을 개발하는 동안, 우리는 사용하려는 jar, 사용할 jar 버전, 함께 연결하는 방법이 필요합니다. 모든 웹 어플리케이션에는 Spring MVC, Jackson Databind, Hibernate 코어 및 Log4j와 같은 유사한 요구사항들이 있습니다. 그래서 우리는 이러한 jar들의 서로 호환되는 버전들을 따로 선택을 해주어야 했습니다. 이런 복잡도를 줄이기 위해서 스프링 부트는 SpringBoot Starter라고 불리는 것을 도입했습니다. 

차이점 

1) Embed Tomcat을 사용하기 때문에, (Spring Boot 내부에 Tomcat이 포함되어있다.) 따로 Tomcat을 설치하거나 매번 버전을 관리해 주어야 하는 수고로움을 덜어준다.

2) starter을 통한 dependency 자동화 :
아마 Spring 유저들이 가장 열광한 기능이 아닐까 싶다. 과거 Spring framework에서는 각각의 dependency들의 호환되는 버전을 일일이 맞추어 주어야 했고, 때문에 하나의 버전을 올리고자 하면 다른 dependeny에 까지 영향을 미쳐 version관리에 어려움이 많았다. 하지만, 이제 starter가 대부분의 dependency를 관리해주기 때문에 이러한 걱정을 많이 덜게 되었다.

3) XML설정을 하지 않아도 된다.

4) jar file을 이용해 자바 옵션만으로 손쉽게 배포가 가능하다.
Spring Actuaor를 이용한 애플리케이션의 모니터링과 관리를 제공한다.

참고 : 

https://sas-study.tistory.com/274

https://velog.io/@courage331/Spring-%EA%B3%BC-Spring-Boot-%EC%B0%A8%EC%9D%B4

GOOD 정리 : https://msyu1207.tistory.com/m/entry/Spring-VS-Spring-Boot-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90?category=640981 

http://dawoonjeong.com/spring-spring_mvc-vs-spring_boot-vs-spring_mvc/

렌더링이란? 

서버로 부터 받은 내용을 브라우저 화면에 표시하는 것

CSR : Client Side Rendering -> 클라이언트 측에서 렌더링을 하는것

SSR : Server Side Rendering -> 서버측에서 렌더링을 하는것

서버사이드 렌더링 (SSR)

페이지를 이동할때마다 (서버에) 새로운 페이지를 요청한다.

그렇기에 페이지의 내용은 모두 서버 연산을 통해서 렌더링 하고 완성된 페이지를 렌더링 한다.+

HTML 초기에는 이러한 서버 사이드 렌더링을 사용해야만 했습니다. 서버에 .html 페이지를 업로드하고, 서버가 요청을 따라 사용자의 브라우저에 출력하는 방식이었죠. HTML 초기에는 대부분 단순한 텍스트와 정적인 이미지를 표시했으므로, 서버 사이드 렌더링에 큰 문제가 없었습니다.

오늘날 웹사이트는 애플리케이션 수준으로 진화했으며, 사용자는 웹사이트에서 메시지를 전성하고, 정보를 업데이트하고, 쇼핑을 하기도 합니다. 그런데 서버 사이드 렌더링은 요청이 발생할 때마다 웹사이트 정보 전체를 요청하는 방식이므로, 사용자가 특정 기능을 실행하기 위해 단 한 번의 클릭을 했을 뿐인데 사이트 전체가 다시 로딩되야 하는 문제가 발생하기 시작했습니다.

클라이언트 사이드 렌더링은 이러한 문제를 어느 정도 해결합니다.

장점

• 검색엔진 최적화 (SEO) 가능
  서버 사이드 렌더링을 통해 얻을 수 있는 가장 큰 장점이다.
• 성능개선
  첫 렌더링된 html 을 클라이언트에게 전달해 주기때문에 초기로딩속도를 많이 줄여줄 수 있다. 자바스크립트 파일을 불러오고 렌더링 작업이 완료되기 전에 사용자가 사이트 컨텐츠를 이용할 수 있게된다.

단점

• 프로젝트의 복잡도
• 페이지 이동시 화면이 깜빡 거린다.
• 서버 렌더링에 따른 부하가 발생

클라이언트 사이드 렌더링 (CSR)

클라이언트에서 렌더링을 하는 방식이다.

첫 요청할때 한페이지만 불러오고, 사용자의 행동에 따른 필요한 부분만 다시 읽어들인다.

브라우저의 자바스크립트를 통해 상호작용을 합니다.

클라이언트 사이드 렌더링에서는 사용자가 '클릭'을 하거나 동작을 실행할 때, 더 많은 페이지 요소가 추가됩니다. 즉, 서버 사이드 렌더링과의 차이점이라면 서버에 문서를 요청하는 것이 아니라, 브라우저에서 이를 처리한다는 것입니다. 즉, 자바스크립트를 통해 새로운 콘텐츠를 불러오고, 삭제할 수도 있는 것이 클라이언트 사이드 렌더링입니다.

클라이언트 사이드 렌더링은 속도 면에서 우수한데, 새로운 콘텐츠를 표시하기 위해 전체 페이지가 아닌 웹페이지의 아주 일부만 불러오기 때문입니다. 그러나 애플리케이션 규모가 커짐에 따라 필요한 자바스크립트도 증가하여 페이지가 다른 면에서 무거워질 수도 있습니다.

장점

첫 요청할때 한페이지 만 불러오게 된다.
제가 자주 사용하는 React 를 보면 index.js 만 불러오게 된다.
( Single Page Application)

그후 , 사용자의 행동에 따른 필요한 부분만 다시 읽어들이기 때문에
서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 인터렉션을 기대할 수 있다.

즉 , 필요한 부분만 리로딩 없이 서버로 부터 받아서 화면을 갱신하게 된다.

단점

• 초기 구동속도가 느리다 .
• 검색엔진 최적화가 어렵다.

참조 : 

https://velog.io/@ash3767/%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8-%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81

https://oneroomtable.tistory.com/entry/%EC%84%9C%EB%B2%84-%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EA%B3%BC-%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8-%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94

https://brownbears.tistory.com/411

https://jaroinside.tistory.com/24

https://dsc-sookmyung.tistory.com/96

정의

OpenID Connect는 OAuth 2.0 프로토콜을 사용하여 빌드된 개방형 표준 및 단순 ID 프로토콜입니다.

이렇게 하면 클라이언트 애플리케이션은 OpenID Connect 제공자(OP)가 사용자의 ID를 검증하기 위해 수행하는 인증을 신뢰할 수 있습니다.

OpenID Connect는 인증 및 권한 부여에 OAuth 2.0을 사용하고 사용자를 고유하게 식별하는 ID를 빌드합니다.

기능 

OAuth는 유저 인증을 곧바로 제공하지 않지만 권한 부여를 위한 엑세스 토큰을 제공한다.

OpenID Connect는 권한부여 서버에 의해 작동하는 인증 시스템을 기반으로 클라이언트가 사용자를 판단할 수 있게 해준다.

권한부여 서버에 유저 로그인과 동의를 요청할 때, openid라는 스코프를 정의하면 OpenID Connect 사용이 가능하다. 

openid는 OpenID가 필요되는 권한부여 서버에 필수적인 스코프이다.

장점

OpenID의 장점은 디지털 정체성과 사용자 활동 일관성에 있습니다.

우선 웹 사이트마다 사용자 계정명이 달라지는 일이 줄어들고, 글을 쓰고 댓글을 달고 별점을 매기는 등 온라인 활동이 한 계정으로 이루어지므로 인터넷 사용자의 고유 식별이 가능해집니다.

OAuth와의 차이

• OAuth 2.0은 권한 부여를 위한 것이다.
• OpenID Connect는 인증을 위한 것이다.

아마 '권한 부여'와 '인증'이 헷갈릴 수 있는데, 차이점은 다음과 같다.

• 인증(Authentication)은 내가 소통하는 주체가 어떤 것인지 확신하는 것이다.
• 권한 부여(Authorization)는 소통하는 주체가 리소스에 접근할 수 있는지 아닌지에 대해 확인하는 프로세스이다.

authentication(인증)은 당신이 누구인지에 대한 것이고, authorization(권한 부여)은 당신이 어떤 권한을 가졌는지에 대한 것이다.

참조 : 

https://www.ibm.com/docs/ko/sva/9.0.7?topic=methods-openid-connect-oidc-authentication 

https://velog.io/@jakeseo_me/Oauth-2.0%EA%B3%BC-OpenID-Connect-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%A0%95%EB%A6%AC

https://d2.naver.com/helloworld/24942

정의

JSON Web Token의 약자로 전자서명 된 URL-safe의 JSON입니다.

전자서명은 JSON의 변조를 체크를 할 수 있다.

표준

JWT의 표준은 JWS와 JWE가 있다

JWS (JSON Web Signature)은 간단히 말하면 “JSON으로 전자 서명을하여 URL-safe 문자열로 표현한 것”입니다.

JWE (JSON Web Encryption)는 “JSON을 암호화하여 URL-safe 문자열로 표현한 것” 입니다.
서명은 서명 할 때 사용한 키를 사용하여 JSON이 손상되지 않았는지 확인 할 수 있도록하는 것입니다. 
URL Safe는 말 그대로 URL에 포함 할 수없는 문자를 포함하지 않는 것입니다.

구성 

JWT는 세파트로 나누어지며, 각파트는 점으로 구분하고 xxxxx.yyyyy.zzzzz로 표현된다.

순서대로 헤더(Header) + 페이로트 (Payload) + 서명 (Signature)

Base64url인코딩을 사용한다.

Header는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다. 첫째는 토큰의 유형 (JWT)을 나타내고, 두 번째는 HMAC, SHA256 또는 RSA와 같은 해시 알고리즘을 나타내는 부분입니다.

{
    "alg": "ES256",
    "kid": "Key ID"
}

Payload는 토큰에 담을 클레임(claim) 정보를 포함하고 있습니다. Payload 에 담는 정보의 한 ‘조각’ 을 클레임이라고 부르고, 이는 name / value 의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임 들을 넣을 수 있습니다.
클레임의 정보는 등록된 (registered) 클레임, 공개 (public) 클레임, 비공개 (private) 클레임으로 세 종류가 있습니다.

{
    "iss": "jinho.shin",
    "iat": "1586364327"
}

마지막으로 Signature는 secret key를 포함하여 암호화되어 있습니다.

결과

eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLn
NoaW4ifQ.eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRC9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6Imp
pbmhvLnNoaW4ifQ.MEQCIBSOVBBsCeZ_8vHulOvspJVFU3GADhyCHyzMiBFVyS3qAiB7Tm_ME
Xi2kLusOBpanIrcs2NVq24uuVDgH71M_fIQGg

기존방식과 비교

기존방식은 토큰은 이후의 모든 서비스 호출에 사용됨.

서비스를 받기 위해서는 토큰의 유효성을 확인하여 세부정보를 쿼리해야함

참조에 의한 호출 형태의 모든 서비스는 항상 상호작용할 때 다시 접속해야됨

JWT를 사용하면, 토큰이 필요한 모든 정보를 포함하고 있어 참조가 필요없기 때문에 마이크로서비스 자체에서 유효성을 검증함

프로세스

1. 사용자가 id와 password를 입력하여 로그인을 시도합니다.

2. 서버는 요청을 확인하고 secret key를 통해 Access token을 발급합니다.

3. JWT 토큰을 클라이언트에 전달 합니다.

4. 클라이언트에서 API 을 요청할때  클라이언트가 Authorization header에 Access token을 담아서 보냅니다.

5. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환합니다.

6. 클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰기반 인증 메커니즘을 제공합니다.

사용처

• 회원 인증: JWT 를 사용하는 가장 흔한 시나리오 입니다. 사용자가 로그인을 하면, 서버는 사용자의 정보를 기반으로한 토큰을 발급합니다.
  그 후, 사용자가 서버에 요청을 할 때 마다 JWT를 포함하여 전달합니다. 서버는 클라이언트에서 요청을 받을때 마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 사용자가 요청한 작업에 권한이 있는지 확인하여 작업을 처리합니다.
  서버에서는 사용자에 대한 세션을 유지 할 필요가 없습니다. 즉 사용자가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 사용자가 요청을 했을때 토큰만 확인하면 되므로 세션 관리가 필요 없어서 서버 자원과 비용을 절감할 수 있습니다.

• 정보 교류: JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법입니다. 그 이유는, 정보가 서명이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지, 또 정보가 도중에 조작되지는 않았는지 검증할 수 있습니다.

참조 : 

http://www.opennaru.com/opennaru-blog/jwt-json-web-token/

https://meetup.toast.com/posts/239

간단 설명 : 

OAuth에서 Resource Server (리소스를 가지고 있는 서버)는 Resource Owner(리소스의 소유자)에게 인증을 받음으로써, 해당 Client(리소스가 필요한 사용자)가 Resource에 접근할 수 있는지 확인합니다.

쉽게 말해 개별 사용자에 대해 가능한 허가를 주고, 사용자들은 허가받은 정보만 얻을 수 있다는 것입니다.

정의 : 

Oauth는 인증을 위한 표준 프로토콜로 한 인터넷 서비스의 기능을 다른 서비스에서도 사용하도록 하는 것입니다. 예를 들어 어떤 쇼핑몰에서 상품을 하나 구매하는데 SNS에 홍보를 해주면 할인을 해준다고 합시다. 사용자가 여기에 동의해서 SNS에 자동으로 홍보글을 작성했습니다. 여기서 SNS에 자동으로 글을 작성한 것이 바로 OAuth를 활용한 것입니다.

과정 : 

1. 사용자가 클라이언트 서비스에 접속한다.
2. 사용자가 로그인을 위해 서버의 Oauth서비스를 선택한다.
3. 사용자는 서버의 Oauth 페이지로 이동해 인증 과정을 거친다.
4. 인증 과정이 끝나면 클라이언트가 지정한 URL로 서버에서 파라미터에 인증 코드를 붙여서 리다이렉트 한다.
5. 리다이렉트된 URL에 붙어 온 파라미터를 읽고 클라이언트는 여기서 온 정보와 클라이언트 id와 비밀번호를 붙여서 서버에 액세스 토큰을 요청한다.
6. 액세스 토큰을 제대로 받았다면 이 액세스 토큰으로 클라이언트는 사용자의 데이터를 서버에게 요청할 수 있다.
7. 액세스 토큰은 빠르게 만료되며 6과정에서 같이 받은 만료가 긴 refresh 토큰으로 재발급 받을 수 있습니다.

참고 : 

https://gdtbgl93.tistory.com/180

https://velog.io/@maintain0404/Oauth2%EC%99%80-OpenID

OAuth의 등록 과정 : https://tldud2404.tistory.com/41

OAuth의 과정 : https://hyunleedev.tistory.com/19

https://d2.naver.com/helloworld/24942