우당탕탕 우리네 개발생활

API문서는 개발팀끼리의 협업에 있어 반드시 필요합니다. API문서가 존재하지 않는다면, API를 사용해야 하는 당사자가 매번 직접 코드를 분석하여 필요한 스펙을 알아내야 할지도 모르겠습니다.  저는 백엔드개발자로서 API문서를 여러번 작성해 봤습니다. Google Docs와 OpenAPI를 통해 작성을 해봤었는데 OpenAPI에 더 매력을 느끼게 되었습니다. Google Docs는 무난하고 익숙했습니다. 어려서부터 '한글'을 주로 사용하면서 docs와 비슷한 환경에서의 문서작성을 해본 경험이 있었기 때문에 프로그램 내 도구들을 사용하는데 어려움이 없었습니다. 하지만 다목적 프로그램이니 만큼 형식이 없어 API문서의 필요한 요소들을 전부 만들어야 하는 부분이 큰 단점으로 여겨졌습니다. 실제로 제가 Ato..

백엔드 서버를 구성하면서 중요하게 생각하고 있는 것 중 하나는 정교한 validation입니다. 보통 저는 서버를 구축한 이후 API 문서를 작성합니다. 각 API 마다 Request에 필요한 파라미터들의 타입명시를 잘해놓고 테스트도 곧잘 합니다.(API문서에 명시한 스펙으로 말이죠.) 하지만 온갖 다양한 타입의 파라미터들을 Request에 담아 테스트를 하다 보면 예기치 않은 에러들을 마주하는 상황이 종종 생깁니다. 예기치 않은 에러라는 것은 문서에 명시하지 않은 에러코드를 나타낸다는 뜻이고 이는 해당 API를 사용하는 클라이언트 입장에서 핸들링할 수 없게 됩니다. 이로 인해 생길 수 있는 피해가 적다고 해도 이는 치명적인 상황으로 여기는 게 맞다고 생각합니다. 이런 생각으로 저는 validation적..

현업에서 Expressjs + mongoose의 조합으로 대부분의 서버작업을 진행했습니다.mongoose의 편리성으로 인해 덕을 많이 봤던터라 Nestjs와의 조합도 기대가 되었습니다. Nestjs의 공식사이트에서 가이드를 쉽게 접할 수 있었습니다. 이를 토대로 Nestjs + mongoose환경을 구축해 본 경험을 풀어보겠습니다. https://docs.nestjs.com/techniques/mongodb Documentation | NestJS - A progressive Node.js frameworkNest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaS..

Externally defined environment variables are visible inside Node.js through the process.env global. We could try to solve the problem of multiple environments by setting the environment variables separately in each environment. This can quickly get unwieldy, especially in the development and testing environments where these values need to be easily mocked and/or changed.https://docs.nestjs.com/t..

몽고DB(MongoDB←HUMONGOUS)는 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템이다. NoSQL 데이터베이스로 분류되는 몽고DB는 JSON과 같은 동적 스키마형 도큐먼트들(몽고DB는 이러한 포맷을 BSON이라 부름)을 선호함에 따라 전통적인 테이블 기반 관계형 데이터베이스 구조의 사용을 삼간다. 이로써 특정한 종류의 애플리케이션을 더 쉽고 더 빠르게 데이터 통합을 가능케 한다. 관계형 데이터베이스 - 위키백과, 우리 모두의 백과사전위키백과, 우리 모두의 백과사전. 관계형 데이터베이스(關係形 Database, Relational Database, 문화어: 관계자료기지, 관계형자료기지, RDB)는 키(key)와 값(value)들의 간단한 관계를 테이블화 시킨 매우 간ko.wikipedia.org..