[1] 아는 만큼 보이는 백엔드 개발

백엔드 개발자를 준비하면서 어떤 것들을 준비해야하는지 감을 잡을 때, 입문자들을 위한 책이다. 그렇기 때문에 정말 기본지식 정도가 적혀 있었다.

한 가지의 서비스를 만들려면 어떤 flow로 백엔드 개발을 하게되는지 알 수 있다. 가볍게 읽기 좋은 책이었다.

---

REST API 설계 규칙

• URI에 동사가 아닌 명사 사용하기
• 자원의 계층 관계는 /로 나타내기
• 소문자만 사용하며 명사와 명사를 구분할 때는 -를 사용하기
  • https://api.sports.com/social_login - X
  • https://api.sports.com/social-login - O
  • 해당 부분은 프로젝트를 진행하면서 놓쳤던 부분이었는데 덕분에 알게 되었다.

---

GraphQL

REST API는 중식당처럼 백엔드 개발자가 미리 만들어놓은 API만 요청할 수 있다. 하지만, GraphQL은 마라탕 식당처럼 원하는 데이터를 직업 요청할 수 있다. 이름에 QL(쿼리 언어)이라는 말이 붙은 것도 이 때문이다. 프론트엔드 개발자가 필요한 데이터를 직접 질의하고 개발의 주도권을 가지려 한다면 GraphQL을 도입할 것을 추천한다.

---

도커

도커는 컨테이너 기술을 이용해 웹 애플리케이션을 배포하고 실행하는 오픈 소스 플랫폼이다. 웹 애플리케이션을 만들고 실행하는 데 필요한 요소(JDK, JAR 파일 등)를 포함해 하나의 이미지로 만든 후, 이 이미지를 활용해 컨테이너를 생성하고 해당 컨테이너에서 웹 애플리케이션을 실행한다. 도커는 컨테이너 기술의 장점을 최대한 활용할 수 있도록 컨테이너간 통신을 위한 네트워크 구성 기능, 여러 컨테이너를 동시에 관리하기 위한 오케스트레이션 기능, 컨테이너 이미지를 저장하고 관리하는 기능 등을 제공한다.

*서버 클러스터에서 다수의 컨테이너를 관리하는 프로세스를 컨테이너 오케스트레이션이라고 한다. 대표적인 컨테이너 오케스트레이션에는 쿠버네티스, 도커 스웜, 아파치 메소스 등이 있다.

---

아키텍처 종류

• 모놀리식 아키텍처

  • 예: 3티어 아키텍처(표현 계층/논리 계층/데이터 계층)
  • 단점
    • 높은 결합도, 높은 복잡성, 단일 데이터베이스, 전체 시스템의 중단 가능성, 개발 프로세스의 복잡성

• 마이크로서비스 아키텍처

  • 여러 개의 작은 서비스 단위로 분해해 각각의 서비스를 독립적으로 개발, 배포, 운영하는 방식
  • 장점
    • 관심사 분리, 분산 데이터 관리, 개발과 배포의 용이성, 높은 탄력성

• 서버리스 아키텍처

  • 개발자가 서버를 신경 쓰지 않아도 되는 아키텍처
  • BaaS, FaaS와 같은 클라우드 기반의 서버리스 아키텍처 사용 가능

---

[아는 만큼 보이는 백엔드 개발] - <정우현, 이인, 김보인> 中