<div id="readability-page-1" class="page"><div><h2 id="cbde">시작</h2><p id="cc31">먼저, 콴다 팀에서 API-First Approach의 시작은 Next QANDA API Raid (<a rel="noopener ugc nofollow" target="_blank" href="/how-qanda-team-solves-problems-together-backend-frontend-team-raid-dev-culture-5a5ba7419cd">👉 콴다 팀 Raid 문화 알아보기</a>)였습니다. qandaapis라는 Git Repository가 2021년 12월에 처음 만들어지고, Next QANDA API Raid는 2022년 1월부터 본격적으로 시작하였습니다.</p><p id="36b7">이 Raid를 통해 풀고자 했던 문제의식은</p><ol><li id="9cf3">설계 단계부터 기술적인 API 설계/리뷰 프로세스 부재</li><li id="50f0">제품 개발 과정의 효율화</li><li id="04f4">명확한 API Spec 기반의 소통 기반 마련</li></ol><p id="b31f">정도로 정리해볼 수 있을 것 같습니다. 그래서 다음을 Next QANDA API Raid의 목표로 삼았습니다.</p><ol><li id="3bc5">Good API가 무엇인지 정의하고, 구성원들이 같은 그림을 바라볼 수 있도록 한다.</li><li id="cd60">Good API가 지속적으로 생산/운영될 수 있는 시스템을 만든다.</li><li id="4bc9">API First Approach가 개발 문화로 자리 잡도록 한다.</li></ol><p id="d594">이 Raid의 결과로 qandaapis라는 Monorepo를 바탕으로 한, API-First Approach 기반 API 설계/리뷰 프로세스를 마련할 수 있었습니다. (이하, qandaapis라 함은 Git Repository를 지칭함과 동시에 이러한 API 설계/리뷰 프로세스를 통칭합니다.)</p><p id="6a09">이어서, API-First Approach를 적용해 나가던 과정을 소개해 보겠습니다.</p><h2 id="cc62">제품 개발 과정</h2><p id="d09d">전통적인 제품 개발 과정을 생각해보면, 다음과 같이 기획과 디자인 이후 요구사항을 분석하고, Server 개발을 진행하고 이후 API 개발이 진행되면서 이후 Client(및 Web, 이하 Native Client와 Web을 Client로 통칭합니다.) 개발이 진행됩니다.</p><figure><figcaption>일반적인 제품 개발 과정</figcaption></figure><p id="bb18">이처럼 기획부터 제품 출시까지 선형적으로 진행되기 마련인데, 이 글에서는 개발 과정을 중점적으로 다루고자 합니다.</p><p id="b34a">Flow chart와 같이 대체로 비지니스 로직들을 Server 중심으로 개발을 하기 대문에, 요구 사항 분석 이후 Server가 어떤 API들이 필요한지 고려하고 먼저 개발을 시작하게 됩니다. 물론 Client에서는 Server API가 나오기 전까지 기다리는 동안, UI/UX 개발을 진행 할 수 있습니다.</p><p id="9f85">비즈니스 요구사항에 따라서 어떠한 기능들은 각 파트 별 개발 소요 기간이 제각각 일 수 있어서, 그 중에서도 Server에서 API 개발 및 전달까지 걸리는 시간이 길어지는 경우 병목이 되어 이후 Client개발 기간에도 영향을 줄 수 있습니다.</p><h2 id="3455">API-First Approach</h2><p id="73d3">API-First Approach는 이름에서도 알 수 있듯이 API 설계를 우선시하는 전략입니다. 앞서 언급한 바와 같이 전통적인 제품 개발 과정에서 Server에서 API를 개발하는 동안 Client는 UI/UX를 개발하고, Server에서 개발된 API를 이후에 연동하는 순서로 진행됩니다.</p><p id="aae2">그러나 API-First Approach에서는 API 설계 단계를 앞당겨 진행함으로써, Server와 Client 개발이 UI/UX에 국한되지 않고 비즈니스 로직까지 병렬적으로 이루어질 수 있게 됩니다. 또한, 각 파트의 개발자들이 API 설계 과정에서 함께 참여하여 리뷰하게 되므로, Client 연동 단계에서 API 수정 요구사항이 줄어들게 됩니다.</p><p id="7993">이외에도 다양한 장점들을 간단히 정리해보면,</p><ol><li id="b2eb">✨ 효율성 — Server, Client 병렬 개발</li><li id="cbdb">📃 명확한 API Spec 및 문서화</li><li id="f609">👨‍💻 이를 바탕으로 한 생산성 증가</li></ol><h2 id="5d9a">qandaapis — google AIP</h2><p id="6d1b"><a href="https://google.aip.dev/" rel="noopener ugc nofollow" target="_blank">Google AIP (API Improvement Proposals)</a>는 Resource 중심의 설계 원칙과, API 설계 규칙 등 상세한 API 설계 가이드를 제공합니다. 앞에서 소개한 바와 같이 콴다 팀에서는 이를 모티브로 Next QANDA API Raid를 진행하여, Google AIP를 스터디하고 기술적으로 우리팀의 개발 프로세스에 녹여낼 방법을 함께 논의하였습니다.</p><p id="37a7">AIP에서는 IDL (Interface Definition Language)로써 Protocol Buffers(이하, protobuf)를 사용하여 API명세를 작성하고 기술합니다. 따라서, AIP를 벤치마크하기 위해 protobuf를 선택하였는데, 콴다 <a href="https://stackshare.io/mathpresso-qanda/qanda" rel="noopener ugc nofollow" target="_blank">팀 기술 스택</a>으로 사용 중인 개발 언어 (Kotlin, Go, Python)에 사용하는 데에도 무리가 없었습니다.</p><p id="831c">qandaapis를 설명하기 전에 AIP 설계 원칙 중 핵심이 되는 Resource-oriented design에 대해서 간단히 알아보고, qandaapis로 넘어가 보고자 합니다.</p><h2 id="4c85">Resource-oriented design</h2><p id="1b12"><a href="https://google.aip.dev/121" rel="noopener ugc nofollow" target="_blank">Google AIP에서는 거의 모든 설계 가이드가 Resource를 중심으로 이루어집니다.</a> 기존 RESTful API 설계에서도 Resource를 중심으로 API를 설계한다는 점은 다르지 않지만, 사실 우리가 RESTful API를 설계하던 모습을 떠올려 보면 Resource가 중심이 되지 않았다는 점을 깨달을 수 있습니다.</p><p id="c5bb">RESTful API 설계에서 path에는 verb를 사용하지 않고, HTTP Method가 verb 역할을 하게 하는 등의 가이드 들이 있지만, 전면에 Resource 설계가 나오지는 않습니다. 그렇다 보니, 일관된 Resource 설계가 이루어지기 어려웠고 원칙을 쉽게 어기게 되었습니다. 사실상 Resource-oriented 보다는 Action-oriented로 API를 설계해왔습니다.</p><p id="cc7a">Google AIP에서 Resource-oriented design에서는 먼저 Resource를 먼저 설계한 뒤, 이를 바탕으로 한 CRUD를 작성합니다.</p><p id="ec8c">예를 들어, Medium과 같은 블로그 서비스를 (정말 단순하게) 설계해 본다고 가정해 보겠습니다. 먼저, User 정의가 필요하지만 이는 생략하고, 하나의 글을 나타내는 Post를 Resource로 정의해 보겠습니다.</p><figure></figure><p id="88e8">대략, 여러 형태의 block들을 정의하고, draft와 publish를 구분하는 published상태를 두었습니다. 또한, 5 line에서 pattern을 보면 User를 parent로 가집니다.</p><p id="f21f">그리고 CRUD를 위한 PostService를 정의합니다.</p><figure></figure><p id="a38d">이러한 구조에서 draft상태의 post 작성을 완료하고, publish를 하는 시나리오를 생각해보면</p><ol><li id="dac6">Post를 조회하고</li><li id="049a">published를 true로 바꾸고</li><li id="6a03">UpdatePost를 호출하면됩니다.</li></ol><p id="f30b">만약 RESTful API형태로 만들어 가며, publish를 하는 경우에</p><p id="cf2d">POST /api/v1/users/{user id}/posts/{post id}/publish</p><p id="d44a">와 같은 Action-oriented로 만들었을 수도 있습니다.</p><p id="63b7">이처럼, 비즈니스 요구사항을 분석하고 Resource-oriented로 Resource정의를 잘 할 수만 있다면, API는 자연스럽게 대부분 CRUD형태에서 충족시킬 수 있고 Resource를 바탕으로 단순하고, 직관적이고, 일관된 API를 가져갈 수 있습니다.</p><blockquote><p id="b7fd">tip. protobuf 및 gRPC를 작성하면서 Google AIP 가이드를 따르고 있는지, <a href="https://linter.aip.dev/" rel="noopener ugc nofollow" target="_blank">Google API Linter</a>를 통해 체크 및 CI Pipeline에 자동화 할 수 있습니다.</p></blockquote><h2 id="e9a8">qandaapis</h2><p id="c766">qandaapis는 각 서비스 API 명세를 Google AIP를 바탕으로 gRPC로 작성하는 Monorepo입니다. (Naming은 <a href="https://github.com/googleapis/googleapis" rel="noopener ugc nofollow" target="_blank">googleapis/googleapis</a>를 벤치마크하였습니다)</p><p id="a29b">단순히 API 설계가 목적이라면 잘 알려진 OpenAPI Specification(aka. Swagger)로 API 명세를 작성할 수도 있습니다. 하지만, 자칫 명세와 구현이 달라질 수 있다는 점이 우려되는 지점이었고, 문서로만 존재하는 API-First Approach가 되지 않도록 실제 개발까지 명세가 이어지도록 제약을 두고자 하였습니다.</p><p id="cb29">Google AIP를 따라 protobuf/gRPC로 API를 설계하면서 다음과 같은 개발 flow를 가져감에 따라, 설계 Spec이 구현까지 이어지며 설계 문서와 구현이 따로 관리되는 문제를 해소할 수 있었습니다.</p></div><div><p id="8b5b">콴다 팀 제품 Server 메인 기술 스택이 Kotlin, Spring인 만큼 언어와 framework를 지원해야 하는데, gRPC는 Java는 물론 Kotlin도 지원하고 있습니다. 다만 gRPC를 Client에서 직접 호출하기에 제약이 있다보니, Google AIP와 같이 <a href="https://google.aip.dev/127" rel="noopener ugc nofollow" target="_blank">HTTP Transcoding</a>이 필요한 상황이었습니다. 리서치를 통해서 <a href="https://armeria.dev/" rel="noopener ugc nofollow" target="_blank">Armeria</a>가 Spring Integration도 지원하고 Google AIP의 HTTP Transcoding도 지원함을 알게 되어 이를 바탕으로 한 Pipeline을 구성하게 되었습니다.</p><h2 id="2b0f">qandaapis — How to</h2><p id="74d7">Google AIP를 따르며 protobuf /gRPC를 작성하면서, 필수로 import해야하는 Protobuf package들이있으며, 이를 언어별로 빌드를 해야 합니다.</p><p id="b310">Kotlin언어로 Stub을 생성하기 위한 도구로는 grpc-kotlin을 사용합니다.</p><p id="5691">qandaapis에서 Kotlin을 멀티모듈로 빌드하기 위해 Gradle Project를 만들고, 적절히 구성한 다음, protobuf를 빌드하기 위해 <a href="https://github.com/grpc/grpc-kotlin/blob/master/compiler/README.md" rel="noopener ugc nofollow" target="_blank">grpc-kotlin</a>을 참고하여 구성합니다. (상세한 protobuf dsl은 <a href="https://github.com/google/protobuf-gradle-plugin" rel="noopener ugc nofollow" target="_blank">protobuf-gradle-plugin</a>을 참고합니다.)</p><figure></figure><p id="7bfa">이런식으로 Gradle Project를 셋팅 한 뒤, 다음과 같은 간단한 User 및 User Service를 정의해보겠습니다.</p><figure></figure><p id="b557">이를 빌드 후 실제 이 서비스를 구현할 프로젝트에서 당겨오면, 다음과 같이 gRPC를 구현할 수 있습니다.</p><figure></figure><p id="ab22">이렇게, qandaapis에서 gRPC형태로 API Spec을 제일 먼저 설계 및 코드 리뷰와 같이 리뷰하는 과정을 거치기 때문에 API-First Approach를 실제 개발 환경에서 달성할 수 있습니다.</p><h2 id="1c81">Armeria</h2><p id="68f0">그래서, 서버에서 gRPC를 구현하는데 어떻게 Client의 HTTP 요청을 처리할 수 있는지에 대해서, Armeria를 살펴봅니다.</p><p id="7e9d"><a href="https://armeria.dev/" rel="noopener ugc nofollow" target="_blank">Armeria</a>라는 opensource는 홈페이지에 다음과 같이 기술되어 있습니다.</p><blockquote><p id="2b14"><em>Armeria</em> is your go-to microservice framework for any situation. You can build any type of microservice leveraging your favorite technologies, including <a href="https://grpc.io/" rel="noopener ugc nofollow" target="_blank">gRPC</a>, <a href="https://thrift.apache.org/" rel="noopener ugc nofollow" target="_blank">Thrift</a>, <a href="https://kotlinlang.org/" rel="noopener ugc nofollow" target="_blank">Kotlin</a>, <a href="https://square.github.io/retrofit/" rel="noopener ugc nofollow" target="_blank">Retrofit</a>, <a href="https://www.reactive-streams.org/" rel="noopener ugc nofollow" target="_blank">Reactive Streams</a>, <a href="https://spring.io/projects/spring-boot" rel="noopener ugc nofollow" target="_blank">Spring Boot</a> and <a href="https://www.dropwizard.io/" rel="noopener ugc nofollow" target="_blank">Dropwizard</a>.</p></blockquote><p id="fb59">중요한 점은, Spring에 통합하여 사용할 수 있으며, 여러 protocol (HTTP, gRPC, etc.) 요청들을 하나의 코드베이스로 처리할 수 있도록 지원하는 것이 특징이라고 할 수 있습니다. 또한, 앞서 언급만 하고 넘어간 <a href="https://google.aip.dev/127" rel="noopener ugc nofollow" target="_blank">HTTP Transcoding</a>을 지원하기 때문에, Armeria를 사용하면 gRPC 구현으로 HTTP, gRPC모두 대응할 수 있게 됩니다.</p><p id="9dca">Armeria를 Spring에 연동하는 방법은 <a href="https://armeria.dev/docs/advanced-spring-boot-integration" rel="noopener ugc nofollow" target="_blank">문서</a>를 참고하면 되고, <a href="https://github.com/line/armeria/blob/armeria-1.25.2/grpc/src/main/java/com/linecorp/armeria/server/grpc/GrpcServiceBuilder.java#L662-L702" rel="noopener ugc nofollow" target="_blank">GrpcServiceBuilder.enableHttpJsonTranscoding</a>를 참고하면 됩니다.</p></div></div>

매스프레소 팀블로그 - Medium

Resource-Oriented 설계, 그리고 qandaapis
안녕하세요.콴다 팀에서 Server 개발을 하는 Joshua 입니다.
이 글에서는 API-First Approach를 간략히 알아보고, 콴다 팀에서는 이를 바탕으로 기존 개발 프로세스에서 어떤 문제점들을 개선하였는지 알아봅니다.
시작
먼저, 콴다 팀에서 API-First Approach의 시작은 Next QANDA API Raid (👉 콴다 팀 Raid 문화 알아보기)였습니다. qandaapis라는 Git Repository가 2021년 12월에 처음 만들어지고, Next QANDA API Raid는 2022년 1월부터 본격적으로 시작하였습니다.
이 Raid를 통해 풀고자 했던 문제의식은
설계 단계부터 기술적인 API 설계/리뷰 프로세스 부재
제품 개발 과정의 효율화
명확한 API Spec 기반의 소통 기반 마련
정도로 정리해볼 수 있을 것 같습니다. 그래서 다음을 Next QANDA API Raid의 목표로 삼았습니다.
Good API가 무엇인지 정의하고, 구성원들이 같은 그림을 바라볼 수 있도록 한다.
Good API가 지속적으로 생산/운영될 수 있는 시스템을 만든다.
API First Approach가 개발 문화로 자리 잡도록 한다.
이 Raid의 결과로 qandaapis라는 Monorepo를 바탕으로 한, API-First Approach 기반 API 설계/리뷰 프로세스를 마련할 수 있었습니다. (이하, qandaapis라 함은 Git Repository를 지칭함과 동시에 이러한 API 설계/리뷰 프로세스를 통칭합니다.)
이어서, API-First Approach를 적용해 나가던 과정을 소개해 보겠습니다.
제품 개발 과정
전통적인 제품 개발 과정을 생각해보면, 다음과 같이 기획과 디자인 이후 요구사항을 분석하고, Server 개발을 진행하고 이후 API 개발이 진행되면서 이후 Client(및 Web, 이하 Native Client와 Web을 Client로 통칭합니다.) 개발이 진행됩니다.
이처럼 기획부터 제품 출시까지 선형적으로 진행되기 마련인데, 이 글에서는 개발 과정을 중점적으로 다루고자 합니다.
Flow chart와 같이 대체로 비지니스 로직들을 Server 중심으로 개발을 하기 대문에, 요구 사항 분석 이후 Server가 어떤 API들이 필요한지 고려하고 먼저 개발을 시작하게 됩니다. 물론 Client에서는 Server API가 나오기 전까지 기다리는 동안, UI/UX 개발을 진행 할 수 있습니다.
비즈니스 요구사항에 따라서 어떠한 기능들은 각 파트 별 개발 소요 기간이 제각각 일 수 있어서, 그 중에서도 Server에서 API 개발 및 전달까지 걸리는 시간이 길어지는 경우 병목이 되어 이후 Client개발 기간에도 영향을 줄 수 있습니다.
API-First Approach
API-First Approach는 이름에서도 알 수 있듯이 API 설계를 우선시하는 전략입니다. 앞서 언급한 바와 같이 전통적인 제품 개발 과정에서 Server에서 API를 개발하는 동안 Client는 UI/UX를 개발하고, Server에서 개발된 API를 이후에 연동하는 순서로 진행됩니다.
그러나 API-First Approach에서는 API 설계 단계를 앞당겨 진행함으로써, Server와 Client 개발이 UI/UX에 국한되지 않고 비즈니스 로직까지 병렬적으로 이루어질 수 있게 됩니다. 또한, 각 파트의 개발자들이 API 설계 과정에서 함께 참여하여 리뷰하게 되므로, Client 연동 단계에서 API 수정 요구사항이 줄어들게 됩니다.
이외에도 다양한 장점들을 간단히 정리해보면,
✨ 효율성 — Server, Client 병렬 개발
📃 명확한 API Spec 및 문서화
👨‍💻 이를 바탕으로 한 생산성 증가
qandaapis — google AIP
Google AIP (API Improvement Proposals)는 Resource 중심의 설계 원칙과, API 설계 규칙 등 상세한 API 설계 가이드를 제공합니다. 앞에서 소개한 바와 같이 콴다 팀에서는 이를 모티브로 Next QANDA API Raid를 진행하여, Google AIP를 스터디하고 기술적으로 우리팀의 개발 프로세스에 녹여낼 방법을 함께 논의하였습니다.
AIP에서는 IDL (Interface Definition Language)로써 Protocol Buffers(이하, protobuf)를 사용하여 API명세를 작성하고 기술합니다. 따라서, AIP를 벤치마크하기 위해 protobuf를 선택하였는데, 콴다 팀 기술 스택으로 사용 중인 개발 언어 (Kotlin, Go, Python)에 사용하는 데에도 무리가 없었습니다.
qandaapis를 설명하기 전에 AIP 설계 원칙 중 핵심이 되는 Resource-oriented design에 대해서 간단히 알아보고, qandaapis로 넘어가 보고자 합니다.
Resource-oriented design
Google AIP에서는 거의 모든 설계 가이드가 Resource를 중심으로 이루어집니다. 기존 RESTful API 설계에서도 Resource를 중심으로 API를 설계한다는 점은 다르지 않지만, 사실 우리가 RESTful API를 설계하던 모습을 떠올려 보면 Resource가 중심이 되지 않았다는 점을 깨달을 수 있습니다.
RESTful API 설계에서 path에는 verb를 사용하지 않고, HTTP Method가 verb 역할을 하게 하는 등의 가이드 들이 있지만, 전면에 Resource 설계가 나오지는 않습니다. 그렇다 보니, 일관된 Resource 설계가 이루어지기 어려웠고 원칙을 쉽게 어기게 되었습니다. 사실상 Resource-oriented 보다는 Action-oriented로 API를 설계해왔습니다.
Google AIP에서 Resource-oriented design에서는 먼저 Resource를 먼저 설계한 뒤, 이를 바탕으로 한 CRUD를 작성합니다.
예를 들어, Medium과 같은 블로그 서비스를 (정말 단순하게) 설계해 본다고 가정해 보겠습니다. 먼저, User 정의가 필요하지만 이는 생략하고, 하나의 글을 나타내는 Post를 Resource로 정의해 보겠습니다.
https://medium.com/media/89db5448ef227df153b8c7de30bea161/href
대략, 여러 형태의 block들을 정의하고, draft와 publish를 구분하는 published상태를 두었습니다. 또한, 5 line에서 pattern을 보면 User를 parent로 가집니다.
그리고 CRUD를 위한 PostService를 정의합니다.
https://medium.com/media/64237b9f02606583bbba1f5d5c7905f7/href
이러한 구조에서 draft상태의 post 작성을 완료하고, publish를 하는 시나리오를 생각해보면
Post를 조회하고
published를 true로 바꾸고
UpdatePost를 호출하면됩니다.
만약 RESTful API형태로 만들어 가며, publish를 하는 경우에
POST /api/v1/users/{user id}/posts/{post id}/publish
와 같은 Action-oriented로 만들었을 수도 있습니다.
이처럼, 비즈니스 요구사항을 분석하고 Resource-oriented로 Resource정의를 잘 할 수만 있다면, API는 자연스럽게 대부분 CRUD형태에서 충족시킬 수 있고 Resource를 바탕으로 단순하고, 직관적이고, 일관된 API를 가져갈 수 있습니다.
tip. protobuf 및 gRPC를 작성하면서 Google AIP 가이드를 따르고 있는지, Google API Linter를 통해 체크 및 CI Pipeline에 자동화 할 수 있습니다.
qandaapis
qandaapis는 각 서비스 API 명세를 Google AIP를 바탕으로 gRPC로 작성하는 Monorepo입니다. (Naming은 googleapis/googleapis를 벤치마크하였습니다)
단순히 API 설계가 목적이라면 잘 알려진 OpenAPI Specification(aka. Swagger)로 API 명세를 작성할 수도 있습니다. 하지만, 자칫 명세와 구현이 달라질 수 있다는 점이 우려되는 지점이었고, 문서로만 존재하는 API-First Approach가 되지 않도록 실제 개발까지 명세가 이어지도록 제약을 두고자 하였습니다.
Google AIP를 따라 protobuf/gRPC로 API를 설계하면서 다음과 같은 개발 flow를 가져감에 따라, 설계 Spec이 구현까지 이어지며 설계 문서와 구현이 따로 관리되는 문제를 해소할 수 있었습니다.
콴다 팀 제품 Server 메인 기술 스택이 Kotlin, Spring인 만큼 언어와 framework를 지원해야 하는데, gRPC는 Java는 물론 Kotlin도 지원하고 있습니다. 다만 gRPC를 Client에서 직접 호출하기에 제약이 있다보니, Google AIP와 같이 HTTP Transcoding이 필요한 상황이었습니다. 리서치를 통해서 Armeria가 Spring Integration도 지원하고 Google AIP의 HTTP Transcoding도 지원함을 알게 되어 이를 바탕으로 한 Pipeline을 구성하게 되었습니다.
qandaapis — How to
Google AIP를 따르며 protobuf /gRPC를 작성하면서, 필수로 import해야하는 Protobuf package들이있으며, 이를 언어별로 빌드를 해야 합니다.
Kotlin언어로 Stub을 생성하기 위한 도구로는 grpc-kotlin을 사용합니다.
qandaapis에서 Kotlin을 멀티모듈로 빌드하기 위해 Gradle Project를 만들고, 적절히 구성한 다음, protobuf를 빌드하기 위해 grpc-kotlin을 참고하여 구성합니다. (상세한 protobuf dsl은 protobuf-gradle-plugin을 참고합니다.)
https://medium.com/media/ca95b0b9b203ce3723ce5cc837800aec/href
이런식으로 Gradle Project를 셋팅 한 뒤, 다음과 같은 간단한 User 및 User Service를 정의해보겠습니다.
https://medium.com/media/f0532c6191c754f3f74326e981cfe993/href
이를 빌드 후 실제 이 서비스를 구현할 프로젝트에서 당겨오면, 다음과 같이 gRPC를 구현할 수 있습니다.
https://medium.com/media/246716cda380675f814a4ad6cd4686aa/href
이렇게, qandaapis에서 gRPC형태로 API Spec을 제일 먼저 설계 및 코드 리뷰와 같이 리뷰하는 과정을 거치기 때문에 API-First Approach를 실제 개발 환경에서 달성할 수 있습니다.
Armeria
그래서, 서버에서 gRPC를 구현하는데 어떻게 Client의 HTTP 요청을 처리할 수 있는지에 대해서, Armeria를 살펴봅니다.
Armeria라는 opensource는 홈페이지에 다음과 같이 기술되어 있습니다.
Armeria is your go-to microservice framework for any situation. You can build any type of microservice leveraging your favorite technologies, including gRPC, Thrift, Kotlin, Retrofit, Reactive Streams, Spring Boot and Dropwizard.
중요한 점은, Spring에 통합하여 사용할 수 있으며, 여러 protocol (HTTP, gRPC, etc.) 요청들을 하나의 코드베이스로 처리할 수 있도록 지원하는 것이 특징이라고 할 수 있습니다. 또한, 앞서 언급만 하고 넘어간 HTTP Transcoding을 지원하기 때문에, Armeria를 사용하면 gRPC 구현으로 HTTP, gRPC모두 대응할 수 있게 됩니다.
Armeria를 Spring에 연동하는 방법은 문서를 참고하면 되고, GrpcServiceBuilder.enableHttpJsonTranscoding를 참고하면 됩니다.
콴다 팀의 Server 에서 API-First Approach를 구현하기 위해 사용한 기술들을 간략히 소개해 보았습니다. 모든 내용을 다루지는 못했지만, 콴다 팀의 Server 개발 과정에서 주요 기술과 개발 flow에 대한 개요를 드릴 수 있었습니다.
🌏글로벌 Top 교육 앱 QANDA(콴다)를 함께 만들어 갈 Backend 개발자들을 기다리고 있습니다! ➡️ 공고 확인하기
API-First Approach로 개발 시작하기 was originally published in 콴다 팀블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

API-First Approach로 개발 시작하기

댓글