웹 애플리케이션 프레임워크의 기초

Web Application Framework

• 웹 서버 개발의 모든 걸 제공함
  • 등장배경: 웹 서버로는 정적인 resource만 반환이 가능하다보니 동적 웹 페이지 반환을 위해 Application의 동적 반환 기능을 요구하게 됨
    • Web Application Server = WATS가 등장함
    • 각 언어마다 Web Application 개발을 위한 Framework를 가지고 있음
      • ex.) Python - Django, Java - Spring, JS - Express.js
    • 제공하는 기눙
      • Request Mapping: 어떤 요청에 따라 어떤 Method를 사용할 지
      • Serialization / Deserialization: JSON과 객체를 변환함
      • Thread 관리: 다량의 요청을 받기 위해 Multi Thread가 필요하여 할당 및 관리를 함
        • 두가지 Thread가 있음
          • 요청 처리를 위한 Thread
          • DB 접속을 위한 Thread
      • DB 동시성 제어: DB 조작에 대한 각 요청들의 동시성 제어
      • Security: 서버에 대한 마구잡이식 요청을 날리지 못하게 하는 방어수단
      • Authentication / Authorization - 어떤 페이지 / API를 요청할 때 권한이 맞는 요청을 보내는지 확인하는 방어체계

---

Interface

• 추상 (Interface): 사용법
  • Interface는 유저 입장에서 사용만 하면 되기때문에, 그 내부의 원리 (구체)는 알 필요가 없다
  • 사용 스펙: Program (Application)혹은 웹 서버의 사용법 (어떤 요청 시 -> 어떤 응답 반환합니다)
• 구체 (Concrete): 원리
  • Interface를 처리하기 위함
  • Interface는 사용만 하면 되기에 그 원리를 언제든 바꿀 수 있다
  • 상세 로직: 어떤 요청시 -> 어떤 응답을 반환하기 위한 방법은 수없이 많고, 유저는 신경 쓸 필요가 없다
    

    

API (Application Programming Interface)

• API: Application 사용을 위한 Interface
• Interface: Application (Program) 혹은 Web Server에서 어떤 요청을 보내면 어떤 응답을 받을 수 있는지에 대한 스펙
• 스펙 == API == Interface

---

Library & Framework

"개발의 제어권이 어디에 있는가로 구별됨"

• Library: 단일 문제 해결을 위한 단일 도구
  • 목적이 뚜렷함
  • 상세 구현(Concrete)체를 제공하고, 개발자는 필요한 기능을 사용하기 위해 Library를 가져와 코드를 "합친다"
    • 합치기 위해서는 코드를 결합 시켜야하는데 이때 Library에 대한 지식이 뛰어나야함
      • 어설프게 사용하면 동작하지 않음
      • 합친다: 개발자는 Library의 사용에 대한 책임과 모든 제어권을 가진다
        • 흐름 제어권 = 개발자의 몫 (책임)
  • 연결의 책임이 개발자에게 있음
• Framework: 다수 문제 해결을 위한 도구의 집합
  • 다수의 Library제공 = 개발에 필요한 라이브러리들을 한곳에 묶어, 개발 편의성 제공
    • 설정이 너무 많아질 수 있어 아는 만큼 조율해서 사용이 가능함
  • 다수의 Interface 제공 = 개발을 위한 껍데기를 제공할뿐, 필요한것은 직접 구현 혹은 다른 라이브러리를 가져와 꽂는다
    • 어떻게 사용해야할지, 어떻게 동작하는지에 대한 지식이 필요함
  • 개발자는 필요한 기능을 사용하기 위해 Library를 가져와 코드를 "꽂는다"
    • 쓰고싶은 Library를 결정한 후 꽂아 넣으면 된다
    • 그 부분에 해당되는 Logic만 짜면 된다
      • 나머지 부분을 Framework가 대신 해준다
        • 아주 쉽다!
          • 개발자의 역량에 상관 없이 쓰고 싶은 Library를 가져다가 꽂으면 해결된다
          • 자유도가 매우 높음
          • 흐름 제어권 = Framework의 몫
          • "연결의 책임이 Framework에게 있음"
          • IoC (Inversion of Control): 제어권의 역전
          • 개발, 흐름 제어권이 개발자에게서 Framework로 이동함

---

Package Manager

• Framework를 사용할 때 꼭 필요함
• Controls Library Versions
• Web Application Framework는 많은 수의 라이브러리가 필요하기에
  1. 어떤 라이브러리를 사용할지
  2. 어떤 버전을 사용할지
     에 대해 관리가 필요함
• Framework 사용 시 라이브러리에 대한 버전 관리를 위한 Package Manager가 필요하다
  

  

• devDependencies: 개발할때만 필요한 Library이다
  • devDependencies 전부가 dependencies에 있을때 Bundle의 용량이 매우커짐
    • Bundling을 최적화 하기 위해 쓰인다

---

Database: 데이터 조회 및 조작

• CRUD = 데이터 조회 및 조작
• 동적 데이터를 저장하는 저장소이기에 데이터를 식별할때는 무조건 ID가 필요함

Transation:

• 대량의 트레픽이나 다수 요청이 DB에 접근할때 동시성을 제어함
• ex.)
  • 다수의 웹 서버 (대량 트레픽) -> 단일 DB에 접속할 때 -> 충돌 (서로 DB를 쓰겠다고 충돌이 일어남)
  • 하나의 웹 서버에서 다수의 요청 -> 단일 DB에 접속할 때 -> 충돌 (서로 DB를 쓰겠다고 충돌이 일어남)
• DB가 하나라 일어나는 문제
  • 이중화가 필요함 (이후에 다룰 내용)
    • 읽기만을 위한 DB 여러게 + 쓰기만을 위한 DB 한개
      • Writing DB가 한개인 이유: Synchronization issue (= too hard to implement)
• Transaction: 단일 DB에 다수의 접근이 충돌이 나지 않게 번호표를 주고, 순서대로 처리함

---