백엔드에서 살아남기

FCM (Firebase Cloud Messaging)

DTO는 계층 간 데이터 전달을 위해 사용하는 객체이다. DTO는 순수하게 데이터를 전송하기 위한 객체이기 때문에 비즈니스 로직은 포함되어 있지 않다

한국어기초사전의 검색 플랫폼을 공개하여 다양하고 재미있는 서비스 및 애플리케이션을 개발할 수 있도록 오픈한 API이다. 한국어기초사전에 구축된 양질의 사전 정보를 개인 또는 기관에서 오픈 API를 이용해 자유롭게 이용할 수 있다!

MSA로 프로젝트를 진행하던 중, CQRS를 위해 CUD를 하는 DB와 Read를 위한 DB를 따로 두자는 이야기가 나왔다. 이렇게 DB를 2개 두면서 CUD를 위한 DB를 연결하는 작업과 Read를 위한 DB를 연결하는 작업을 따로 하게 되었다.

OpenFeign FeignClient FeignClient는 MSA 환경에서 마이크로 서비스 간 동기적 통신을 지원하는 선언적 웹서비스 클라이언트이다. RestAPI를 사용하기 위한 추상화된 인터페이스를 제공하며, 인터페이스에는 호출하려는 타겟 메서드의 정보를 담아

한 번에 프로젝트를 여러 개 진행하게 되면서 로컬에서 테스트를 위한 DB를 만들 때 이름을 짓기가 곤란한 문제가 발생했다.

개발을 진행하면서 if문과 switch문을 각각 언제 사용하는 게 좋은지에 대한 고민이 항상 있었다.

Path Variable, Query Parameter, Request Body는 API 개발을 하다보면 반드시 알아야 하는 내용이다. 그리고 각각을 어느 상황에 써야 하는지도 확실하게 알고 사용을 해야 하는데,

API 개발을 하면서 유효성 검사를 진행하다 보면 기본 어노테이션으로는 검증이 불가능한 경우가 있다. 그럴 때는 직접 어노테이션을 개발해서 유효성 검사를 진행할 수 있다. 이렇게 유효성 검사를 위한 커스텀 어노테이션을 만들어두면 다른 곳에서도 편리하게 사용할 수 있다.

정적 웹 사이트(React, Vue) 등을 CI/CD 방식으로 배포할 수 있는 서비스이다.

Docker 환경에서 Selenium으로 웹 크롤링을 해야 할 일이 있었다. 로컬 환경에서는 따로 chromium을 다운받지 않고도 실행이 잘 되었지만, Docker 환경에서 돌려보니 크롬을 인식하지 못해서 WebDriver가 초기화되지 않는 문제가 발생했다.

업무를 진행하다가 프로젝트 전용 깃허브 계정을 사용해야 하는 일이 있었다. 해당 프로젝트 전용 깃허브 계정도 사용해야 하고, 기존에 쓰던 깃허브 계정도 사용해야 하는 상황에서 어떻게 하면 두 계정을 동시에 사용할 수 있을지 알아보게 되었다.

테스트 코드를 작성하면서 테스트 환경을 구축하는 것에 어려움을 겪었다. 특히 테스트를 할 때는 보통 내장 DB인 H2를 많이 사용하게 되는데, H2를 사용하면 테스트 환경과 운영 환경 사이에 간극이 생기는 경우가 있었다. 이를 해결할 수 있는 방법이 없을까 찾아보다가

테스트 코드를 작성하다보면 중복 코드가 많이 발생한다. 특히 멀티 모듈 환경에서는 test 폴더의 코드를 다른 모듈에서 사용할 수 없기 때문에 모듈마다 같은 코드를 반복해서 작성해야 했다.

API가 제대로 동작하는 것을 확인하기 위해서 통합 테스트를 작성하게 되었다. Spring Boot에서는 RestAssured라는 라이브러리를 사용해서 통합 테스트를 작성한다는 것을 알게 되었고, 하는 김에 사용 방법을 정리해보기로 했다.

QueryDSL의 NumberExpression을 사용하면서 계산 결과가 예상과 달라 문제를 겪은 경험이 있다. 해결 방법은 간단했지만 같은 문제를 여러 번 겪었고, 방심해서 놓치기 쉬운 부분이라 생각이 되어 블로그로 과정을 남겨두려 한다!

사이드 프로젝트를 진행하면서 회원가입 시 디스코드 웹훅을 전송하도록 하는 로직을 담당하게 되었다. 생각했던 것보다 더 쉽게 할 수 있었고, 이번에 정리해두면 나중에도 활용할 수 있을 것 같아 블로그를 작성하게 되었다.

API를 개발하다 보면 HTTP 요청과 응답을 로깅해야 할 때가 있다. 단순히 log.info()로 남기기에는 매번 코드에 직접 작성해야 하고, 민감 정보 마스킹이나 환경별 설정 분리까지 고려하면 상당히 번거로워진다. 이를 해결할 수 있는 방법을 찾다가 Zalando에

기존에 OCI DevOps로 빌드-배포 파이프라인을 설정하다가 잘 되지 않아 GitHub Actions를 사용하여 파이프라인을 구축하게 되었다. GitHub Actions를 사용하니 복잡한 설정 없이 deploy.yml 파일 하나로 자동 배포 설정이 가능했다.

프로젝트를 진행하면서 Slack 메시지에 버튼을 달고, 클릭 시 서버에서 이를 처리하는 기능이 필요했다. Slack에서 상호작용을 하는 방법은 과정을 정리해두면 나중에도 도움이 될 것 같아 블로그로 남긴다.

이전에 Slack Interactivity를 Request URL 방식으로 구성했는데, 로컬 테스트 시마다 ngrok을 켜고 URL을 갱신해야 하는 번거로움이 있었다.

이번에 진행한 프로젝트가 웹 기반이다 보니, 전부터 한 번 써보고 싶었던 Spring Security를 통해 소셜 로그인을 구현할 수 있는 기회가 생겼다.