1주차 : Simple 미션을 진행하며 생각해 볼까요?

[goldentrash]

생각해 볼까요?

다음은 알아두면 재밌을, 어쩌면 몰라도 크게 상관없을 내용들이기도 합니다.
관심이 있는 주제(최소 1개)에 대해서 더 알아보고 스터디원과 생각을 교류해 봅시다!

1. Web은 무엇일까요? Web의 역사에 대해 아시나요?
   • Server Client Pattern은 무엇일까요?
   • WWW의 창시자가 WWW를 비난한 사실을 알고 계신가요?
2. Layered Architecture는 왜 사용할까요?
   • Layered Architecture의 단점은 무엇일까요?
3. RESTful API란 무엇일까요?
   • safe, idempotent, cacheable에 대해 아시나요?
     • idempotent는 왜 중요할까요? PRG Pattern에 대해 아시나요?
   • 대체제는 어떤게 있을까요? GraphQL, gRPC, SOAP에 대해 들어보셨나요?
4. WAS와 Web Server의 차이를 알고 계신가요?
   • 현대의 WAS는 Web Serving 능력이 출중하다고 합니다. 그런데도 왜 아직 둘을 나누는게 더 일반적일까요?
5. Server Framework은 어떤 것들이 있나요? Spring Framework가 다른 Framework에 비해 가지는 장단점은 무엇인가요?
   • Framework란 무엇인가요? Library랑 다른게 무엇일까요?
   • php를 아시나요? Nest.js와 Django는 어떤가요?
   • Java를 사용하는 Server Framework가 Spring이라고요? 그럼 혹시 Dropwizard에 대해서는 알고 계신가요?

아래에 정리해 주세요!

정리 양식은 자유입니다! 몇 가지 주제에 대해서 알아오셨나요?

[goldentrash]

Server Framework에 대해서...

Spring은 굉장히 대규모 프로젝트입니다. Spring Data, Spring Boot, Spring AI... 정말 많은 프로젝트가 있습니다.
위에 예시로 나온 것 처럼 Dropwizard처럼 jvm 진영에 다른 Server Framework가 존재함에도 불구하고,
대부분의 사람이 jvm Server를 얘기하면 Spring을 떠올리곤 합니다.

Laravel은 자세힌 모르지만 php란 점에서 주변 사람들이 별로 내켜하지 않는 인상을 받았습니다.
하지만 해외에선 여전히 강하다고...?

RoR(Ruby on Rails)은 빠른 개발에 강점을 보여 여러 기업에서 채택했다고 알고 있습니다. 보통 서비스 시작을
RoR로 하고, 이후 점차 Spring과 같은 조금 더 대규모에 적합한 Framework로 migration을 진행한다고 합니다.

Nest.js는 Node.js 진영에서 떠오르는 Server Framework입니다. 다만, 엄격한 구조의 Server를 디자인한다면
Spring을 사용하는게 더 낫지 않느냐, 소위 "그럴 바엔 Spring 쓴다"란 평을 많이 들었습니다.

Go와 Rust는 떠오르는 신흥 강자이지만, 아직까지 Major한 선택지는 아닌 것으로 보입니다.
(두 언어에서 대중적인 Server Framework이 무엇인지는 잘 모르겠네요)

Haskell 혹은 Elixir를 발견하셨다면 도망가시길 권해드립니다. 뉴비가 함부러 건드려선 안 된다고 들었습니다.
어쩌면 여러분과 같은 천재들은 오히려 잘 맞을지도?

[goldentrash]

@chabin37 님이 준비하셨던 내용입니다!

WAS와 Web Server의 차이를 알고 계신가요?

네, Web Server는 정적인 콘텐츠(HTML, 이미지 등)를 클라이언트에게 전달하는 역할을 주로 수행합니다.
반면에 WAS(Web Application Server)는 동적인 웹 애플리케이션을 실행하고 비즈니스 로직을 처리하는 서버입니다.
즉, WAS는 Web Server의 기능에 더해 데이터베이스 연동, 세션 관리 등 복잡한 작업을 수행합니다.

• 웹 서버
  • 정의 : 정적인 콘텐츠(HTML, CSS, 이미지 등)를 제공하는 서버
  • 기능 : HTTP 프로토콜을 이용해 클라이언트에게 웹 페이지 제공
  • 주요 소프트웨어 : Apache, Nginx, IIS
• WAS 서버
  • 정의 : 동적인 콘텐츠(웹 애플리케이션)를 처리하고 제공하는 서버
  • 기능 : 웹 애플리케이션 실행 및 데이터 처리, 웹 서버와 클라이언트 간의 중계 역할
  • 주요 소프트웨어 : Tomcat, JBoss, WebLogic, WebSphere

현대의 WAS는 Web Serving 능력이 출중하다고 합니다. 그런데도 왜 아직 둘을 나누는게 더 일반적일까요?

• 보안 강화: Web Server가 외부 요청을 필터링하고 WAS로 전달함으로써 보안 위협을 줄일 수 있습니다.
• 부하 분산: 정적 콘텐츠는 Web Server가 처리하고, 동적 콘텐츠는 WAS가 처리하여 시스템 부하를 효율적으로 관리할 수 있습니다.
• 유지보수 용이성: 각 서버를 독립적으로 관리하고 최적화할 수 있어 운영 효율성이 높아집니다.
• 스케일링 유연성: 트래픽 패턴에 따라 Web Server나 WAS를 개별적으로 확장할 수 있습니다.

우리가 보는 화면은 Web Server를 활용(빠르고 안정적), 우리의 데이터 관리 등은 WAS를 활용하게 되는 것 같다.

유명한 웹 서버-Apache, WAS서버-Tomcat. 이 둘을 사용하므로써 서버 부하를 방지.

Tomcat5.5부터 Apache기능을 포함하게 되서, Apache Tomcat이라고 부름.

WAS서버를 재시작할 때, Web Server에서 WAS 사용을 제한하면 사용자들의 불편을 줄일 수 있다.

이를 [장애 극복 기능] 이라고 한다.

[goldentrash]

@jhmin99 님이 준비하셨던 내용입니다!

Layered Architecture는 왜 사용할까요?

필요성

• 각 계층의 역할 추상화
  • 시스템을 여러 계층으로 분할함으로써, 각 계층이 특정한 역할과 책임을 가지게 됩니다. 예를 들어, 프레젠테이션 계층은 사용자 인터페이스와 관련된 부분을 담당하고, 데이터 접근 계층은 데이터베이스와의 상호작용을 처리합니다. 이렇게 함으로써 각 계층은 자신의 역할에 집중할 수 있게 되고, 다른 계층의 내부 구현에 대해 알 필요 없이 명확한 인터페이스를 통해 상호작용할 수 있습니다.
• 인터페이스의 추상화
  • 계층 간의 통신은 명확하게 정의된 인터페이스를 통해 이루어집니다. 이는 각 계층이 다른 계층의 내부 구현에 의존하지 않고, 추상화된 인터페이스를 통해 상호작용하게 함으로써 시스템의 유연성과 확장성을 높입니다.
• 테스트 용이성
  • 각 계층이 독립적으로 추상화되어 있기 때문에, 단위 테스트와 통합 테스트를 보다 쉽게 수행할 수 있습니다. 이는 시스템의 품질을 높이고, 버그를 조기에 발견할 수 있게 합니다.

Layered Architecture 일반적인 구조

• Presentation Layer (프레젠테이션 계층):
  • 사용자와의 상호작용을 담당합니다. UI, 웹 페이지, 모바일 앱 등이 포함됩니다.
• Application Layer (애플리케이션 계층):
  • 비즈니스 로직을 처리합니다. 사용자 요청을 처리하고, 데이터 흐름을 제어합니다.
• Business Logic Layer (비즈니스 로직 계층):
  • 애플리케이션의 핵심 비즈니스 규칙과 로직을 구현합니다.
• Data Access Layer (데이터 접근 계층):
  • 데이터베이스나 외부 데이터 소스와의 상호작용을 담당합니다. CRUD (Create, Read, Update, Delete) 작업을 수행합니다.
• Database Layer (데이터베이스 계층):
  • 실제 데이터가 저장되는 계층으로, RDBMS, NoSQL 데이터베이스 등이 포함됩니다.

단점

• 계층 간 오버헤드
  • 계층이 추가될수록 데이터가 각 계층을 통과하면서 발생하는 오버헤드가 커질 수 있습니다. 이는 응답 시간을 증가시키고 시스템의 성능을 저하시킬 수 있습니다.
• 복잡성 증가
  • 계층이 많아질수록 시스템의 전체적인 복잡성이 증가할 수 있습니다. 이는 개발자에게 더 많은 이해와 관리가 필요하게 만듭니다.

RESTful API란 무엇일까요?

• RESTful API는 Representational State Transfer (REST) 원칙을 따르는 API로, 주로 HTTP 프로토콜을 기반으로 합니다. REST는 시스템의 자원을 정의하고, 이 자원에 접근하기 위한 표준화된 HTTP 메소드를 사용하여 데이터를 주고받습니다. RESTful API는 웹의 기본적인 기능을 활용하여 클라이언트와 서버 간의 통신을 단순하고 효율적으로 만듭니다.

• 리소스

• RESTful API에서 모든 것은 리소스로 간주됩니다. 각 리소스는 고유한 URI(Uniform Resource Identifier)로 식별됩니다. 예를 들어, /users/123은 ID가 123인 사용자 리소스를 나타냅니다.

• HTTP 메소드

  • RESTful API는 HTTP 메소드를 사용하여 리소스에 대한 동작을 정의합니다.
    • GET: 리소스 조회
    • POST: 새로운 리소스 생성
    • PUT: 기존 리소스 전체 업데이트
    • PATCH: 기존 리소스 부분 업데이트
    • DELETE: 리소스 삭제

• 무상태성

  • REST는 무상태성을 유지해야 합니다. 즉, 각 요청은 독립적이어야 하며, 서버는 이전 요청의 상태를 저장하지 않습니다.

• 데이터 교환

  • 클라이언트와 서버 간의 데이터 교환에는 일반적으로 JSON이나 XML 형식이 사용됩니다.

• 계층화 시스템

  • RESTful 아키텍처는 계층화된 시스템을 지원합니다. 클라이언트는 중간 서버(프록시, 게이트웨이 등)를 통해 최종 서버와 통신할 수 있습니다.

safe, idempotent, cacheable에 대해 아시나요?

• safe

  • safe 메소드는 서버의 상태를 변경하지 않는 메소드를 의미합니다. 즉, 이러한 메소드는 단순히 데이터를 조회하거나 가져오는 데 사용되며, 서버의 리소스에 영향을 미치지 않습니다.
  • 예시:
    • GET: 리소스를 조회할 때 사용됩니다. 서버의 상태를 변경하지 않습니다.
    • HEAD: GET과 유사하지만, 응답 본문을 포함하지 않고 헤더 정보만 요청할 때 사용됩니다.
  • 특징:
    • 비변경성: 요청을 여러 번 보내더라도 서버의 상태가 변하지 않습니다.
    • 캐싱 가능성: safe 메소드는 캐시될 가능성이 높습니다.

• idempotent (멱등)

  • idempotent 메소드는 같은 요청을 여러 번 보내더라도 서버의 상태가 동일하게 유지되는 메소드를 의미합니다. 즉, 한 번 요청하든 여러 번 요청하든 결과가 동일합니다.

  • 예시:

    • GET: 리소스를 조회하므로 멱등합니다.
    • PUT: 특정 리소스를 업데이트하거나 생성할 때 사용됩니다. 같은 데이터를 여러 번 PUT 요청해도 결과는 동일합니다.
    • DELETE: 특정 리소스를 삭제할 때 사용됩니다. 이미 삭제된 리소스에 대한 DELETE 요청은 아무런 영향을 미치지 않습니다.

  • 비 idempotent 메소드:

    • POST: 새로운 리소스를 생성할 때 사용됩니다. 같은 POST 요청을 여러 번 보내면 여러 개의 리소스가 생성될 수 있습니다.

• cacheable

  • cacheable 메소드는 서버의 응답을 클라이언트나 중간 캐시 서버에 저장할 수 있는 메소드를 의미합니다. 이를 통해 동일한 요청에 대해 서버에 반복적으로 요청하지 않고 캐시된 응답을 사용할 수 있습니다.
  • 예시:
    • GET: 일반적으로 캐시가 가능합니다.
    • HEAD: GET과 유사하게 캐시가 가능합니다.
    • POST, PUT, DELETE: 일반적으로 캐시되지 않습니다. 그러나 특정 조건 하에서는 캐시될 수 있습니다.
      • POST 메서드의 캐싱
        • 특정 API 설계:
          • POST 요청이 리소스 생성뿐만 아니라, 상태 변경을 하지 않는 특정한 경우에 한해 캐시될 수 있습니다. 예를 들어, 검색 쿼리를 POST로 보내는 경우, 동일한 쿼리에 대한 응답을 캐시할 수 있습니다.
      • PUT 메소드의 캐싱
        • 멱등성 보장:
          • PUT 요청은 동일한 데이터를 여러 번 전송해도 결과가 동일하므로, 특정 조건 하에서 캐시될 수 있습니다. 예를 들어, 업데이트된 리소스의 상태를 클라이언트가 자주 조회해야 하는 경우, PUT 응답을 캐시할 수 있습니다.
      • DELETE 메소드의 캐싱
        • 멱등성 보장:
          • DELETE 요청은 동일한 리소스를 여러 번 삭제해도 결과가 동일하므로, 캐시할 수 있는 가능성이 있습니다. 그러나 일반적으로 DELETE 요청 자체는 캐시되기보다는, DELETE 요청 후 해당 리소스에 대한 GET 요청을 캐시 무효화하도록 설계됩니다.
  • 특징:
    • 성능 향상: 캐시를 통해 응답 시간을 줄이고 서버 부하를 감소시킵니다.
    • 일관성 관리: 캐시된 데이터가 최신 상태를 반영하도록 적절한 캐시 제어 헤더(Cache-Control, ETag 등)를 설정해야 합니다.

idempotent는 왜 중요할까요? PRG Pattern에 대해 아시나요?

• idempotent의 중요성

  • 문제 상황 예시:
    • 사용자가 네트워크 문제로 인해 동일한 주문 요청을 여러 번 보냄.
    • 사용자가 브라우저의 새로 고침(F5)으로 인해 POST 요청이 반복됨.
    • 클라이언트 애플리케이션의 오류로 동일한 요청이 여러 번 전송됨.
    • 이러한 상황에서 idempotent를 구현하지 않으면 사용자는 중복 결제를 경험하게 되며, 이는 사용자 경험을 저해하고, 재무적인 손실로 이어질 수 있습니다.
  • Idempotent를 구현하는 방법
    • Idempotency Key 사용
      • Idempotency Key는 클라이언트가 요청을 고유하게 식별할 수 있도록 제공하는 고유한 식별자입니다. 서버는 이 키를 사용하여 동일한 요청을 반복적으로 처리하지 않도록 합니다.
      • 동작 방식:
        • 클라이언트 측:
          • 주문 요청을 보낼 때, 고유한 Idempotency Key를 생성하여 함께 전송합니다.
          • 이 키는 UUID와 같은 고유한 값을 사용하여 생성할 수 있습니다.
        • 서버 측:
          • 요청을 받을 때, Idempotency Key를 확인합니다.
          • 이미 동일한 키로 요청이 처리된 적이 있다면, 이전 응답을 반환하고, 결제를 다시 처리하지 않습니다.
          • 새로운 키라면, 요청을 처리하고 키와 응답을 저장합니다.
    • 중복 체크 및 트랜잭션 관리
      • 서버 측에서 주문이나 결제를 처리할 때, 데이터베이스 수준에서 중복을 방지하는 트랜잭션 관리 기법을 사용할 수 있습니다.
      • 동작 방식:
        • 트랜잭션의 원자성 보장:
          • 주문과 결제 과정을 하나의 트랜잭션으로 처리하여, 모든 작업이 성공적으로 완료되거나 모두 취소되도록 합니다.
        • 고유 제약 조건 설정:
          • 데이터베이스에 주문이나 결제 테이블에 고유 제약 조건(Unique Constraint)을 설정하여, 동일한 주문이 중복으로 생성되지 않도록 합니다.

• PRG pattern

  • PRG 패턴은 웹 애플리케이션에서 주로 사용되는 디자인 패턴으로, 사용자가 폼을 제출한 후 페이지를 새로 고침하거나 뒤로 가기를 할 때 발생할 수 있는 문제를 방지하기 위해 사용됩니다. 특히, 중복된 POST 요청으로 인한 데이터 중복 제출을 방지하는 데 효과적입니다.
    • POST 요청:
      • 사용자가 폼을 제출하면 클라이언트는 서버로 POST 요청을 보냅니다. 서버는 이 요청을 처리하고, 필요한 작업(예: 데이터베이스에 데이터 저장)을 수행합니다.
    • 리디렉션 (Redirect):
      • 서버는 POST 요청을 처리한 후, 클라이언트를 새로운 URL로 리디렉션합니다.
    • GET 요청:
      • 클라이언트는 리디렉션된 URL로 자동으로 GET 요청을 보냅니다. 이 요청은 서버에서 처리된 결과를 보여주는 페이지를 반환합니다.
  • PRG 패턴의 장점
    • 중복 제출 방지:
      • 사용자가 브라우저에서 페이지를 새로 고침해도 POST 요청이 다시 전송되지 않고, GET 요청만 반복되므로 데이터 중복 제출을 방지할 수 있습니다.
    • 사용자 경험 개선:
      • 사용자가 폼을 제출한 후 페이지를 새로 고침하거나 뒤로 가기 했을 때 예기치 않은 동작을 하지 않게 됩니다.
  • PRG 패턴의 단점
    • 추가 요청 발생:
      • POST 요청 후 리디렉션을 통해 GET 요청이 추가로 발생하므로, 네트워크 오버헤드가 증가할 수 있습니다.
    • 복잡성 증가:
      • 서버 측에서 리디렉션 로직을 추가로 구현해야 하므로, 설계가 다소 복잡해질 수 있습니다.
  • PRG 패턴과 idempotent의 관계
    • 비 멱등성 메소드 해결: POST와 같은 비 멱등성 메소드의 경우, PRG 패턴을 통해 중복된 요청으로 인한 문제를 효과적으로 해결할 수 있습니다.
    • 멱등성 메소드와 PRG: 멱등성 메소드인 GET, PUT, DELETE 등의 경우, PRG 패턴의 필요성이 줄어들지만, POST와 같은 비 멱등성 메소드에서는 PRG 패턴이 유용하게 사용됩니다.

대체제는 어떤게 있을까요? GraphQL, gRPC, SOAP에 대해 들어보셨나요?

• GraphQL
  • Facebook에서 개발한 쿼리 언어로, 클라이언트가 필요한 데이터만 정확하게 요청할 수 있도록 설계되었습니다. RESTful API의 단점을 보완하며, 복잡한 데이터 요구사항을 효과적으로 처리할 수 있습니다.
  • 클라이언트가 필요한 데이터의 구조를 정의하여 서버로 요청합니다. 이는 과도한 데이터 전송을 방지하고, 필요한 데이터만 효율적으로 가져올 수 있게 합니다.
  • RESTful API와 달리, GraphQL은 일반적으로 단일 엔드포인트를 사용하여 모든 쿼리와 변형을 처리합니다.
  • GraphQL은 스키마를 통해 데이터의 타입을 명확히 정의하며, 이를 통해 클라이언트와 서버 간의 계약을 명확히 합니다.
  • 구독(Subscription)을 통해 실시간 데이터 업데이트를 지원합니다.
• gRPC
  • Google에서 개발한 오픈 소스 원격 절차 호출(RPC) 시스템으로, 주로 마이크로서비스 간의 효율적인 통신을 위해 사용됩니다. gRPC는 HTTP/2를 기반으로 하며, Protocol Buffers를 사용하여 데이터 직렬화를 수행합니다.
  • HTTP/2의 멀티플렉싱, 흐름 제어, 헤더 압축 등의 기능을 활용하여 고성능 통신을 지원합니다.
  • gRPC는 Protocol Buffers (protobuf)를 사용하여 데이터 직렬화를 수행하며, 이는 JSON보다 더 빠르고 효율적입니다.
  • 클라이언트와 서버 간에 실시간으로 데이터를 주고받을 수 있는 양방향 스트리밍을 지원합니다.
  • 다양한 프로그래밍 언어를 지원하여, 서로 다른 언어로 작성된 서비스 간의 통신을 용이하게 합니다.
• SOAP
  • XML 기반의 메시지 프로토콜로, 주로 웹 서비스 통신을 위해 사용됩니다. REST가 등장하기 이전에 널리 사용되었습니다.
  • SOAP은 WS-* 표준을 통해 보안, 트랜잭션, 메시지 라우팅 등의 다양한 기능을 제공합니다
  • WSDL (Web Services Description Language)을 통해 서비스의 인터페이스를 명확히 정의합니다.
  • HTTP, SMTP, TCP 등 다양한 전송 프로토콜을 지원합니다.
  • WS-Security 표준을 통해 메시지 수준의 보안 기능을 제공합니다.
• 비교

특징	RESTful API	GraphQL	gRPC	SOAP
프로토콜	HTTP	HTTP	HTTP/2	HTTP, SMTP, TCP
데이터 형식	JSON, XML	JSON	Protocol Buffers (이진 형식)	XML
성능	보통	보통	매우 높음	낮음
확장성	높음	매우 높음	높음	낮음
실시간 통신	제한적	지원 (구독)	강력하게 지원	제한적
보안	HTTPS, 토큰 기반 인증	HTTPS, 토큰 기반 인증	TLS, 인증서 기반 보안	WS-Security, 메시지 수준 보안
사용 사례	웹 애플리케이션, 모바일 앱	복잡한 데이터 요구사항이 있는 애플리케이션	마이크로서비스, 실시간 애플리케이션	엔터프라이즈 환경, 높은 보안 요구사항

[goldentrash]

@SIKU-KR 님이 준비하셨던 내용입니다!

Layered Architecture는 왜 사용할까요? 단점은 무엇일까요?

• Layered Architecture : UI Layer, Business Layer, Data Acesss Layer로 논리적인 계층을 분리시켜 개발하는 것.
• 유지보수성, 모듈성, 테스트용이성을 위해 사용한다.
• 복잡성, 성능 저하, 과도한 추상화가 단점으로 작용한다.

RESTful API란 무엇일까요?

• Stateless, Uniform Interface, Resource Representation의 스타일을 지키는 API

safe, idempotent, cacheable에 대해 아시나요? idempotent`는 왜 중요할까요?

• safe: HTTP 메서드 중 GET과 같이 서버의 상태를 변경하지 않는 요청을 "safe"하다고 합니다. 이는 클라이언트가 동일한 요청을 여러 번 보내도 서버의 상태는 변하지 않는다는 의미입니다.
• idempotent: PUT이나 DELETE 메서드는 여러 번 호출해도 같은 결과를 반환해야 하는 특성을 가집니다. 즉, 같은 요청을 여러 번 반복해도 서버의 상태는 동일하게 유지됩니다.
• cacheable: GET 요청의 경우 클라이언트나 중간 서버에서 결과를 캐시할 수 있으며, 이를 통해 성능 최적화가 가능합니다.

PRG Pattern (Post/Redirect/Get 패턴)이란?

PRG (Post/Redirect/Get) 패턴은 웹 애플리케이션에서 POST 요청 후 페이지 새로 고침으로 인해 발생할 수 있는 중복 요청 문제를 해결하기 위해 사용됩니다.

WAS와 Web Server의 차이를 알고 계신가요? 현대의 WAS는 Web Serving 능력이 출중하다고 합니다. 그런데도 왜 아직 둘을 나누는게 더 일반적일까요?

• Web Server: 정적 컨텐츠(HTML, CSS, 이미지 등)를 제공하고, 클라이언트의 HTTP 요청을 처리합니다. 주로 Nginx, Apache 같은 서버가 해당됩니다.
• WAS (Web Application Server): 동적인 웹 애플리케이션을 처리하는 서버로, 비즈니스 로직과 데이터베이스 연동을 처리합니다. Java 기반의 WAS로는 Tomcat, JBoss 등이 있습니다.