nodejs
[SQS, MSA, Nodejs] MSA & Message Queue
요번에 이쁘게 구조도를 만들어 봤다ㅎㅎ (모두가 예쁘다고 좋아했다) 모름지기 개발이란, 성능과 사용성보단, 예쁜게 중요하다. 팀에 합류하고, 공통 모듈을 따로 만들고, 전체 푸시 알람 만들고.. 디비 코멘트도 달고... GPT socket하고 이것저것 했는뎅, 내가 처음으로 와서 한 일은 MSA 및 메시지큐를 도입했다. 푸시 알람이나 AI등 여러 기능들을 묶일 수 있는 공통의 그룹으로 묶고, 분리하려 했다. 이유는 다음과 같다. 1. 특정 섹션에서 병목이 나면, 다른 기능에 영향을 주기 싫었고, 2. 특정 섹션에 더 많은 계산이나 트래픽이 많다면, 부분적으로 스케일아웃, 업을 할 수 없는 구조 였다. 3. 처음에는 리소스가 많이 들어가지만, 정착되면 유지보수에 있어서 리소스가 적어질 것이라 판단했기 때문..
[NodeJs, Notion] Nodejs + Notion database 연동하기 및 만들기
노션에 있는 이런 데이터베이스는 개발자가 아닌 사람들도 편하게 데이터베이스를 만들 수 있고, 접근성도 용이하고 좋은 것 같다. 관련된 쿼리도 제공하고 api도 제공해서 만들기도 괜찮은 것 같고, 이걸 이용해서 나중에 notion-orm을 만들자~ 하고 잠시 생각해서, 누군가 이름을 먹었다.. 코드도 없으면서.. notion-orm, notionorm 둘다 안돼ㅠㅠ 일단 notion으로 뭘 할 수 있을지 하나하나 기록해보려한다. 공식문서 (는 잘되어 있으나, 연결 부분에서 설명이 불친절한 부분도 있었따) Getting started Learn how to make your first API requests using the Notion API developers.notion.com 1. 노션 전체 페이지로..
[NodeJs, Express, Typescript] 전역 에러 핸들링 (express global error handle)
Nest는 @Catch(HttpException) 이런식으로 공식문서에서 쉽게 되어 있던데, Express는 뭔가 불편하다. 내가 여태껏 했던 것들은 API단위에서의 에러를 처리하고, 다음 공통된 에러 미들웨어에서 에러 레벨에 맞게 객체만들고, 클라쪽으로 넘겨서 처리하는 방식이 많았는데, 그렇게 했던 이유는 실력 부족도 있고, 결국은 이게 모든 에러를 다 컨트롤 한다고 잘못된 생각을 했다. 전역에서 에러를 관리하면 더 좋다는 피드백을 들었다. 그전에는 morgan, winston, slack으로 로깅을 할 때도 api단위에서의 에러를 로깅했었다. error.filter.ts import { Request, Response, NextFunction } from 'express'; class AppError..
[NodeJs, Typescript] nodemailer 이메일 보내기
한동안 블로그 글을 못썼다.. 원랜 진짜 작업했던 내용들만 올렸었는데, 최근엔 작업이 아니라 새로온 프론트, 백엔드 분들의 과제를 만들어주고, 온보딩을 도와주고 문서화를하는 일들이 전부였기 때문이다. 새로온 후임자들이랑은 친해져서, 아직까지 친하게 지내고 있다. 여튼 얼마전에 만든 메일 보내기를 기록한다. nodemailer.ts import nodemailer from 'nodemailer'; import MailCodeInterface from '../interface/mailCode.interface'; import 'dotenv/config'; const send = async (data: MailCodeInterface) => { const transporter = nodemailer.creat..
[Nodejs, TypeScript] 도메인 로직 리팩토링
운영하고 있는 배틀 서버의 구조를 바꾸고 싶었다. 일을 해보면서 느끼는건, 기획자나 QA를 하시는 분들과 노션이나 슬렉, 구두로 소통할 때, 'A라는 기능에 ~~을 했을 때 ~~한 문제가 생겼다' 이런 느낌으로 주고 받는게 많은데, 저런 워딩을 나나 혹은 다른 개발자들이 일할 때 '아아~ 특정 API에 문제가 있겠구나', 판단하고 작업을 들어가는 경우가 많았다. 여기서 기획자나 개발자나 모두 똑같은 용어로 소통하면 좋다는 다른 회사 개발팀의 이야기를 듣고, 나름 개선해보기로 했다.. 개선을 결정한 이유는 크게 2가지다. 1. 일단 나는 1인 개발을 쭉 해왔기에, 내가 다 만들어서 어디가 문제인지 찾아갈 수 있지만, 다른 개발자들과 협업하거나, 새로 들어올 내 후임자들이 이해하기 쉬운 구조가 좋을 것 같다..
[Nodejs, GraphQL] Middleware(미들웨어) 만들기
그래프큐엘에서 미들웨어를 쓰고 싶었다. 일단 jwt-token을 활용한 미들웨어를 만들어봤다. memberAuth.middleware.ts import memberService from '../service/member.service'; const memberAuthMiddleWare = async (authorization: string) => { const verifyJwtMemberAuth = await memberService.verifyJwtToken(authorization); const memberInfo = await memberService.getMemberInfo(Number(verifyJwtMemberAuth.memberIdx)); return memberInfo; }; export ..
[NodeJs, GraphQL, Apollo, Express, Prisma, TypeScript] Setting
GraphQL을 검색 서버에서 활용해보고 싶었다. 앱 내에 다양한 검색들이 있었는데, 검색 부분에서 restApi보단, endpoint를 동일하게하고, 프론트에서 원하는 데이터만 축출해가는 디자인 패턴이 더 효율적이라 생각했기 때문이다. 일단 프로젝트 배포전 임의로 셋팅 해봤다. app.ts import express from 'express'; import bodyParser from 'body-parser'; import cors from 'cors'; import apolloServer from './apollo/apolloserver'; import 'dotenv/config'; const main = async () => { const app = express(); app.use(express...
[NestJs, Prisma] Prisma CRUD
회사 내 특정 서비스들을 Nestjs + Prisma 로 바꾸고 싶었다. 기존 프로덕트는 모든게 생쿼리를 날리거나, 내가 직접 만든 orm을 사용했는데. 이게 처음엔 mysql이 뭔지도 모르는 초짜가 sql에 대해 학습하기 좋았지만, 점점 작업하면 할 수록 불편해졌다. 1. 내가 모든 컬럼을 외울 수도 없는 노릇 2. 모든 테이블을 혼자 만든 나도 이런데, 나말고 다른 백엔드 개발자가 보면 더 적응하기 힘들거라 생각 TypeORM과 Prisma중에 선택을 해야 했는데, Prisma를 선택했다. 추후 GraphQL을 사용할 건데, Prisma가 더 적합해 보였다. 단점은 AWS RDS Aurora에서 읽기 전용 DB를 지원하지 않는 다는 거였는데.. (prisma에 미들웨어처럼 넣어서 어거지로 할 수 있긴..