전체 글

이전글에서 REST, gRPC 그리고 GraphQL를 비교해봤습니다. 이번에는 Python의 GraphQL 사용을 돕는 라이브러리를 비교해보려고 합니다. 솔직히 말하자면 FastAPI 유저인 저에게는 FastAPI가 공식문서에서 추천한 Strawberry가 정답으로 자리잡고 있고, 이미 Strawberry를 이용해서 구현했지만 공부하는 차원에서 각 라이브러리의 사용성, 문서화와 개발자 경험(DX), 타입 지원, 웹 프레임워크 통합성, 프로젝트 유지보수 및 커뮤니티 현황을 살펴보겠습니다.왜 라이브러리 비교기준에서 성능이 빠졌을지 의문을 가질 수 있습니다. 하지만 물론 저도 처음에는 알아봤지만 GraphQL 서버 성능은 주로 쿼리 실행 엔진의 효율과 리졸버에서의 I/O 처리 방식에 따라 좌우되며, 세 라이브..

기존에 REST 와 gRPC로 데이터를 서빙하던 FastAPI 서버에 GraphQL을 도입하게 되었습니다. 필드가 많은 데이터를 서빙하는 서버였는데, 다수의 클라이언트에 서로 다른 인터페이스의 API를 서빙해야 했습니다. 그렇다면 REST 보다는 데이터 질의가 유연한 GraphQL을 도입하는게 좋겠다는 결론을 내렸고, 이미 잘 만들어진 라이브러리와 공식문서 덕분에 3일만에 배포할 수 있었습니다. 일단 구현은 했고, 이제는 블로그에 글을 연재하면서 관련 이론과 케이스 스터디를 진행해보려고 합니다. 이번 글에서는 REST와 gRPC 그리고 GraphQL의 개념, 설계철학을 알아보고 성능 특성을 비교하여 향후 프로젝트를 진행할때 적절한 기술을 선택할 수 있는 기반을 다지고자합니다.REST: 리소스 중심의 AP..

Python Web 개발을 FastAPI로 시작하다보니 비동기 상태에서 Python을 다루는게 너무나 당연했습니다. 그동안 막연히 Python을 비동기적으로 쓰려면 asnyc 를 써야지 생각만해왔습니다. 주말을 맞이해서 이번에 그 기반을 닦아보려고 합니다. 오늘은 그래서 asyncio 는 무엇인지 그리고 왜 필요한지, node.js 그리고 Java 와의 차이점은 무엇인지 등을 알아보고 정리하려 합니다.asyncio란 무엇인가?공식 문서에서는 asyncio를 “async/await 문법을 이용하는 동시성(concurrent)처리를 위한 라이브러리" 라고 소개하고 있습니다. 이러한 asyncio 라이브러리를 이용하여 IO bound 되어있는 작업을 효율적으로 처리할 수 있고, 이러한 이유로 고성능 웹 프라임..

gRPC에 대해서 알아보던중 pyi 파일을 처음 보았고, 이 파일이 Python Type System 중 하나인 stub file 이라는 것을 알게되었습니다. stub file 이 무엇인지 궁금해졌고, 이 궁금증은 Python의  Type System 전체로 확장되었습니다. 전반적인 내용을 정리해보고자 합니다. Python 공식문서중 TypeHint Guide에서 많은 내용을 참고했습니다. 왜 Type System이 필요한가?우선 프로그래밍 언어를 구분할때 다음과 같은 기준이 있습니다.타입 캐스팅이 자유로운지에 따라 강 타입/약 타입컴파일시 타입을 체크하는지에 따라 정적 타입/동적 타입이러한 기준에서 봤을때 Python은 약 타입이자, 동적 타이핑 언어입니다. 즉 명시적인 타입 캐스팅 없이 타입 변환이 ..

지난글에서 RPC (gRPC) 를 선택한 이유를 알아봤습니다. 이제는 python 에서 어떻게 gRPC 를 사용할 수 있는지 공유하겠습니다..proto 파일RPC는 엄격한 규칙을 따르기 때문에 IDL(Interface Definication Language)이 제공됩니다. 특히 구글에서 만들고 배포하는 gRPC는 관련 문서와 tool이 잘 구비되어 있어서 구현하기 용이합니다. gRPC를 구현하기 위해 가장 먼저 해야할 것은 서버와 메시지 규약을 정하는것입니다. 이러한 규약은 .proto 파일에 정의됩니다.Service 와 MessagegRPC는 Service를 통해서 호출될 함수를 정의하고, Message 를 통해서 호출 파라미터, 응답 값을 정의합니다.아래 예제는 protobuf bestpractice..

MSA를 구현할때 각 서비스별로 분리된 데이터베이스를 관리합니다. 이 상황에서 화면으로 전달될 데이터가 하나의 서비스에 국한될 가능성은 거의 없을 것입니다. 이때 BFF 와 같이 각 서비스와 통신하여 데이터를 모아주는 역할을 하는 서비스가 존재하게 됩니다.이때 데이터를 동기화하는 다양한 패턴이 있지만, 실시간으로 데이터를 동기화해야하는 경우에는 gRPC 가 적합하다 판단했습니다. 이 글에서는 왜 그렇게 생각했는지 정리했습니다.MSA 에서 데이터 동기화 패턴Chris Richardson의 Microservice Pattern에 따르면 이라는 용어가 적합하지 않을 수 있습니다. 이 글에서 말하는 데이터 동기화 패턴이란 마이크로 서비스 환경에서 사용자의 요구에 따라 일관성있는 데이터를 전달하기 위한 패턴으로..

이 시리즈는 AWS EKS & FastAPI 환경에서 로그를 적용하는 과정을 다루고 있습니다. 전체 시리즈는 다음과 같습니다.- FastAPI log (1) - AWS EKS Fargate 환경에서 log 를 외부시스템에 보내기- FastAPI log (2) -AWS EKS Fargate, 왜 Fluent Bit 인가?- FastAPI log (3) - 설계, 구현- FastAPI log (4) - 개선하기이전 글에서 FsatAPI 의 request, stacktrace를 logging 하는 Middleware 를 만들었습니다. 하지만 이러한 구현 접근에는 결정적인 오류와 개선사항이 있습니다.오류결정적인 오류는 Middleware 에서 Exception 을 catch 하고 있다는 점입니다. FastAPI..

SQLAlchemy 도 Spring의 Transaction 처럼 read-only 를 만드는 기능이 있는지 물어보는 질문이 있었습니다. 이 글의 답변에도 작성했지만, 저도 SpringBoot 를 사용할때는 Transaction 격리수준, 전파수준 등을 엄청 신경썼었는데 FastAPI&SQLAlchemy 를 사용하면서 한번도 이런 고민을 안했습니다.이게 개별 비즈니스 로직을 간단하게 유지할 수밖에 없는 프레임워크의 장점아닌 장점이라고 생각하면서 SQLAlchemy 에서 read-only transaction 을 만드는 방법을 알아보았습니다.  Does SQLAlchemy automatically create a transaction for read-only operations?I am currently l..