[02-02] Web Application Framework

1.1 Web Application Framework

- Java: Spring

- Python: Django

- C#: ASP, NET

- JS: Express.js

 

- 웹 어플리케이션 프레임워크는 다음과 같은 기능을 제공

• RequestMapping : 어떤 요청에 따라 어떤 메서드(함수 혹은 로직)을 수행할것인지
• Thread 관리 : 요청을 처리하기 위한 Thread 할당 및 관리, 데이터베이스 접속을 위한 Thread 할당 및 관리
• 데이터베이스 동시성 제어 : 대량 트래픽 발생 시 데이터베이스 조작에 대한 각 요청들 간의 동시성 제어
  -> Isolation Level(트랜젝션 격리 레벨)
• Serialization / Deserialization : 요청, 응답 시 어플리케이션의 객체와 클라이언트의 JSON 사이 변환
• Security : CORS 규칙 등에 대한 보안 관련 정의 및 처리
• Authentication / Authorization : 인증/인가, 매 요청마다 해당 요청이 권한에 맞게 요청한건지 보안 처리

---

1.2 라이브러리와 프레임워크

라이브러리	단일 문제 해결을 위한 단일 도구 제공 -> 상세 구현체를 제공해줌 -> 라이브러리 사용에 대한 책임과 제어권
	흐름제어권(라이브러리의 사용에 대한 책임과 제어권) => 개발자

출처: asca 수업자료

프레임워크	다수의 문제 해결을 위한 다수의 도구 제공 -> 다수의 라이브러리를 제공하여 개발 편의성을 키움 -> 다수의 인터페이스를 제공하여 기본적 틀 제공     => 껍데기에 대한 제공일 뿐, 직접 구현 or 라이브러리 교체 필요
	흐름제어권(라이브러리의 사용에 대한 책임과 제어권) => 프레임워크 내장이므로 프레임 워크가 갖는다. == IoC(Inversion of Control): 제어권의 역전, 제어권을 기계가 갖는다. ...인간의 시대의 끝이 도래했다.
	모듈화를 통해 함수의 연결에 대한 제어권이 프레임 워크에게 있지만, 개발자는 제어권이 프레임워크에게 있기 때문에 주어진 제약 조건에 따라 상세 구현을 해야한다.

출처: asac 수업자료

---

1.3 웹 어플리케이션 프레임워크 동작 원리

1.3.1 Package Manager: 라이브러리 버전 관리

- 프레임워크는 많은 수의 라이브러리를 갖기 때문에, 어떤 라이브러리를 사용할지, 어느 버전을 쓸지 결정해야 함

    -> 중간 관리자를 두어 관리 == Package Manager

     - JS: npm

     - Python: pip

     - Java: Maven || Gradle

     - Ruby: bundler

---

1.3.2 DB: 데이터 조회 및 조작

- CRUD = 데이터 조회 및 조작 : Create, Read, Update, Delete

- DB는 동적 데이터 저장소이기에 데이터 식별 시, ID를 사용함

    => 고유 ID를 일관적으로 유지하여 일관적인 조회를 충족시켜야 함(기본 키 설정을 잘하자!)

- 일반적으로 고유 식별자로는 숫자 구성의 ID를 사용 but, 경우에 따라 다른 것 사용

Auto Increment ID	(-) 개수 제한 : 최대 Long 을 넘어서는 개수 표현 불가 (-) 추적 가능 : 해커와 같은 악의적 유저가 ID 숫자를 기반으로 다른 자원들에 대한 추론/접근 가능 (-) 성능 : 작은 앱에서는 충분한 성능으로 채택할만한 ID 채번 방식
UUID	: Universally/Globally Unique Identifier (+) 개수 제한 : 128bit 로 사실상 무한 개수 표현 가능 (+) 충돌(Collision Resistance) : 유사난수(Pseudo-Random)로 키 생성 시 충돌 가능성 매우 낮음 (?) 순서 비보장 : 키 그 자체로 의미(Semantic)을 갖지 못함 (-) 길이 : 너무 길고, 순서보장이 되어있지 않아 해당 키값 기반으로 인덱싱을 할때 어려움
CUID	: Collision-Resistant Unique Identifier : 분산 시스템에서 적당한 옵션 (?) 순서 보장(Monotonically Increasing) (+) 길이 : UUID 보다 짧아졌다
NanoID	: 순서 보장이 굳이 필요없지만, CUID 보다 더 짧은 아이디를 원하는 경우

---

1.3.3 Transaction : 대량 트래픽이나, 다수 요청이 데이터베이스에 접근 → 동시성 제어

- Transaction: DB 상태를 변화시키기(접근하기) 위해 수행하는 작업의 단위, 또는 그 작업에 대한 순서

• 다수의 웹 서버에서 (대량 트래픽) → 단일 데이터베이스에 접속 시, 충돌 (서로 데이터베이스 쓰겠다고 싸움)
• 하나의 웹 서버에서 다수의 요청이 → 단일 데이터베이스에 접속 시, 충돌 (서로 데이터베이스 쓰겠다고 싸움)

---

 

깨알 단어 사전

* Singleton: 하나의 instance만 생성 및 공유(전역적 접근을 통해) == 하나 실객체만 존재해야 한다.

    -> 멀티 스레드 환경에서 singleton? "동시성" 발생 가능

        1) Synchronized(동기화) 키워드를 통해 getInstanse() 동기화

            => Lock을 걸어 1개씩 수행하는 방식, 오버 헤드 발생 가능성이 높다.

        2) DCL(Double Checked Locking)

            => 두번의 확인으로 Instance가 없을 때, 생성하는 부분에 동기화로 Lock

            => But, Java의 reodering에 의해 일어난 visibility 문제 발생 ->volatile로 해결해야함

 

* Interface: 입력 값과 출력 값에 대한 추상화적 정의로 이해하면 됨, 즉 어떤 애용에 대한 시그니처를 제공

    -> f(a) = b와 같이 입력 값과 그에 대한 출력만 알면 그 안에 대한 상세 구현은 다른 곳에서 하는..

 

* API(Application Programming Interface): 위의 interface와 같은 의미로 해석

    -> 어떤 요청을 보내면 어떤 응답을 받을지에 대한 스펙(....난 몰라 백에서 해줘)