포스트

2021-08-26-TIL

2021-08-26-TIL

JSON

JSON to POJO

외부 API의 JSON 응답을 받을 클래스를 손으로 만들면 필드가 많을 때 오타가 생기기 쉽다. json2csharp의 JSON to POJO 도구는 JSON 예시를 붙여 넣으면 대응하는 Java 클래스(중첩 객체는 별도 클래스, 배열은 List)를 생성해 준다. 생성된 코드는 출발점으로만 쓰고, 날짜나 숫자 타입, 필드 이름 규칙(@JsonProperty)은 직접 확인해야 한다.

  • https://json2csharp.com/json-to-pojo

DB

DB 문서화

테이블 정의서 같은 DB 문서를 손으로 쓰면 스키마가 바뀔 때마다 갱신을 빠뜨리기 쉽다. 링크된 글은 JDBC로 DB의 메타데이터(테이블, 컬럼, 제약 조건)를 읽고, 엑셀 템플릿 엔진 JETT로 정해진 양식의 문서를 자동으로 뽑아내는 도구를 만든 과정을 소개한다. 문서를 코드로 생성해 두면 마이그레이션 후 다시 실행하기만 하면 된다.

  • https://blog.cometkim.kr/posts/introduction-to-jdbc-jett-renderer/

MSA

마이크로서비스 아키텍처는 하나의 애플리케이션을 작고 독립적으로 배포할 수 있는 서비스들로 나누고, 서비스끼리 API나 메시지로 통신하게 하는 구조다. Red Hat의 설명대로 각 서비스는 하나의 기능을 맡고 독립적으로 개발, 배포, 확장할 수 있다. 장점은 팀별 독립 배포, 부분 확장, 장애 격리이고, 비용은 분산 시스템의 복잡도다. 네트워크 호출 실패와 지연을 다뤄야 하고, 서비스마다 DB가 나뉘면 여러 서비스에 걸친 데이터 일관성을 트랜잭션 하나로 보장할 수 없어서 사가(saga) 같은 패턴이 필요하다. 링크 중에는 MSA 프로젝트 회고와, Microsoft의 .NET 마이크로서비스 설계 가이드가 있다.

  • https://medium.com/byungkyu-ju/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%ED%8C%A8%ED%84%B4-8-8%EC%9E%A5-3cbe2bcbd24c
  • https://jheloper.github.io/2019/01/retrospective-msa-project/
  • https://www.redhat.com/ko/topics/microservices
  • https://bcho.tistory.com/1005
  • https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design

REST API

NHN 글은 REST API 설계의 기본(리소스는 URI로, 행위는 HTTP 메서드로 표현하고, 상태는 응답 코드로 알린다)을 정리한다. Spring 가이드 “Consuming a RESTful Web Service”는 반대편, 즉 다른 서버의 REST API를 호출하는 쪽을 다룬다. RestTemplate의 getForObject()로 요청을 보내고 JSON 응답을 Jackson이 자동으로 객체에 매핑하게 한다.

  • https://meetup.toast.com/posts/92
  • https://spring.io/guides/gs/consuming-rest/

Ktor

Ktor는 JetBrains가 만든 Kotlin 웹 프레임워크로, 코루틴 기반의 비동기 서버와 클라이언트를 만든다. Spring처럼 많은 기능을 기본 제공하기보다 필요한 기능(라우팅, 직렬화, 인증)을 플러그인으로 골라 설치하는 가벼운 구조다. 링크 중 하나는 Spring 개발자가 Ktor를 써 본 비교 글이고, 공식 문서의 응답 페이지는 call.respond()로 응답을 보내고 상태 코드와 헤더를 설정하는 방법을 설명한다.

  • https://ktor.io/learn/
  • https://dev.to/martin/trying-out-ktor-as-a-spring-developer-15m7
  • https://ktor.io/docs/responses.html#parameters

OAuth

소셜 로그인(OAuth)을 붙였을 때 프론트엔드와 백엔드가 각각 어떤 역할을 맡고, 인가 코드와 토큰이 어떤 순서로 오가며, 그 결과로 서비스의 사용자 계정을 어떻게 만들고 연결하는지 정리한 글이다.

  • https://velog.io/@kimyh03/OAuth-%EC%82%AC%EC%9A%A9%EC%9E%90-%EA%B3%84%EC%A0%95-%EA%B4%80%EB%A6%AC-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4frontend-backend

RabbitMQ

RabbitMQ는 AMQP 프로토콜을 구현한 메시지 브로커다. 생산자는 메시지를 큐에 직접 넣지 않고 exchange로 보내고, exchange가 바인딩 규칙(direct, topic, fanout 등)에 따라 큐로 라우팅하면 소비자가 큐에서 꺼내 처리한다. 마이크로서비스 사이를 메시지로 연결하면 호출하는 쪽이 받는 쪽의 응답을 기다리지 않아도 되고, 받는 쪽이 잠시 내려가도 메시지가 큐에 남아 있어 서비스 간 결합과 장애 전파가 줄어든다. 링크된 글들이 RabbitMQ를 쓰는 이유로 드는 점이다.

  • https://velog.io/@cckn/%EB%B2%88%EC%97%AD%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-RabbitMQ%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0
  • https://kamang-it.tistory.com/entry/AMQPRabbitMQRabbitMQ%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EC%99%80-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95-1

Kafka

Kafka는 분산 이벤트 스트리밍 플랫폼이다. 메시지(이벤트)를 토픽별로 파티션에 나눠 순서대로 추가하는 로그에 저장하고, 소비자가 읽은 뒤에도 보존 기간 동안 남겨 둔다. 소비자 그룹 단위로 파티션을 나눠 읽어 병렬 처리하고, 각 소비자는 자신이 어디까지 읽었는지(offset)를 관리한다. 메시지를 소비하면 큐에서 사라지는 전통적인 브로커와 달리 같은 이벤트를 여러 시스템이 각자 다시 읽을 수 있다는 점이 RabbitMQ와의 큰 차이다.

  • https://ellune.tistory.com/29
참고한 자료외부 출처 5

외부 출처

이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다