2024-12-04.md

🗓️ 2024-12-04

🐌 스크럼

• 학습 목표 1. API 아키텍쳐

💡 새로 배운 내용

1. API 아키텍처

• API란
  소프트웨어가 서로 소통하고 데이터를 주고받는 방법을 정의한 규칙과 프로토콜의 집합이다.

• API 아키텍처를 사용하는 이유는
  다양한 서비스마다 서로 다른 요구사항과 사용 사례를 해결하기 위해

2. SOAP (Simple Object Access Protocol)

xml 기반 메시징 프로토콜

• 장점
  • WS-security, WS-Atomictransaction 등의 표준이 지원되기 때문에 높은 보안을 자랑한다.
  • xml은 대부분의 언어와 플랫폼에서 지원되기에 높은 호환성을 보인다.
• 단점
  • xml 자체가 데이터가 크기 때문에 오버헤드가 발생할 수 있다.
  • 데이터 형식이 제한적이다.

3. Restful

url로 자원을 식별 가능한 프로토콜

• 장점
  • 자원을 url로 나타내기 때문에 이해하기 쉽다.
  • 응답으로 xml, json 등을 모두 지원한다.
  • 확장성과 성능이 높다. (요청과 응답이 독립적이고 HTTP 캐싱이 가능하기 때문)
• 단점
  • 명확학 스키마 정의가 없다. (개발자들이 자유롭게 명세서를 정의하기 때문)

4. GraphQL ⭐️

클라이언트가 서버에서 데이터를 빠르게 가져오기 위해 사용하는 쿼리 언어

• 장점

  • api 요청 수가 적어 네트워크 부하 및 서버 부담이 적다.
  • 원하는 데이터만 선택적으로 요청할 수 있다.

• 단점

  • 러닝 커브가 높다.
  • 요청 쿼리가 너무 복잡할 수 있다.

• 🔥 팀원분의 질문: 프론트엔드 개발을 하던 hazel(나)은 해당 아키텍처를 사용해 보신 적이 있으신가요? 없다면 왜일까요? 왜 해당 아키텍처는 잘 이용되지 않는 거 같지요,,?

  • 아직 성장하고 있는 오픈소스이므로 기능 변경이 잦다.
  • 단일 endpoint이기 때문에 HTTP 캐싱이 어렵다.
  • 에러 핸들링이 어렵다.
    • GQL은 성공한 쿼리 데이터는 data 배열에 담기고, 실패한 쿼리 데이터는 error 배열에 담기는데 담긴 에러 객체들은 어디서 어떻게 실패한 건지 정보가 담겨있다. 근데 GQL 특성상 많은 데이터를 받아오기 때문에 더욱 에러 핸들링이 까다로워진다!
  • 백엔드 개발자의 입장에서, RestAPI보다 구현이 복잡하다. 클라이언트에서 보낼 여러 쿼리 조합들에 대응할 수 있는 로직을 구현해야 하기 떄문이다.

5. gRPC

클라이언트가 서버의 함수를 로컬에서 실행하듯 요청을 보내는 원격 프로시저 콜

• 장점
  • 클라이언트와 서버의 언어가 달라도 profobuf를 통해 데이터를 주고 받을 수 있다.
• 단점
  • 러닝 커브가 높다.
  • 브라우저에서 사용하려면 추가적인 라이브러리가 필요하다. (gRPC-Web)

6. Websocket

클라이언트와 서버가 실시간 양방향 통신이 가능한 프로토콜

• 장점
  • connectionful, stateful 하기 때문에 요청 오버헤드가 적다.
• 단점
  • HTTP/1.1에서 동작하기 때문에 구형 브라우저나 서버에서는 동작하지 않을 수 있다.

7. Webhook

서버에서 이벤트 발생시 클라이언트로 알림을 보내는 이벤트 기반 통신 방식

• 장점
  • 하나의 webhook url로 여러 서비스에 연결하여 사용할 수 있다.
  • 폴링을 사용하지 않기 때문에 서버 부하가 적고 효율적이다.
• 단점
  • 네트워크 장애 발생시 클라이언트에게 알람 전송이 정상적으로 이루어지지 않을 수 있다.

👏🏻 오늘의 회고

• 여러 API 아키텍처를 공부했다. 직접 사용해보진 못했지만 예제 코드들을 보며 어떤식으로 동작하는지 알 수 있었다. Webhook과 Rest API는 써봤지만 다른 것들은 초면이라 신기했다. GraphQL은 한 번쯤 써보고 싶다!

🔗 참고 자료 및 링크

• GraphQL 도입시 주의해야 할 점 - 요즘IT
• GraphQL 사용 안 하는 이유