개발을 처음 배웠을때 nestjs로 개발을 시작했었다. 지금 생각해보면 참으로 의아할수도 누군가는 근본없다고 할수도 있을것같다. 아니 express도 모르면서 nest로 시작했다고...? 그래서 일까? 나 스스로도 뭔가 자신이 없었다. 기본을 모르고 무언가를 시작했다는
nestJs는 모듈로 기능을 조립한다고 이전 포스팅에서 언급했었다. 그렇다면 nestJs는 middleware를 사용하지 않는다는 것인가?? 답은 전혀 그렇지 않다 이다. nestJs도 middleware를 사용할수있고 또 많이 사용한다. express에서는 morga
nestjs는 참 많은 기능을 제공해준다. 자체 제공해주는 기능이 많은것은 좋으나 아무래도 어떻게 그 기능이 동작하는지 알지 못한체로 개발하는것은 조금 불안할수 있다. 처음 nestjs를 배울때는 그냥 기능 하나하나 익히느라 그런것들을 신경쓰지 않았었는데 기능이 손에
사용자가 서버에 데이터를 전달해주는 방식은 몇가지가 있다. 대표적으로는 body로 전달할수있으며 url을 이용한 param 그리고 query로 전달하는 방식이 있다. 이외에도 multipart/form-data라던가 form url encoded방식이라던가 있지만 일단
나는 신입 서버개발자로 일하며 내가 이렇게 이렇게 프론트로 부터 데이터를 받을수 있을까? 라고 생각해 주변 프론트개발자 분들에게 물어본적이 많다. "나 이렇게 이렇게 데이터 받고 싶은데 이런형식으로 줄수있어?" 라고 물어보며 로직을 생각한적이 많았던것 같다. 근데 서버
예전에 부트캠프에서 nestjs 관련 공부했을때 custom decorator를 만들어 본적이있다. 사실 그때 무작정 따라 치기 바빠서 이게 커스텀 데코레이터를 만드는건지도 몰랐는데 이번에 공부하면서 "응? 나이거 옛날에 해봤던거 같은데? 그때 했던 그게 커스텀 데코레
드디어... 말로만 들었던 interceptor에 대해 공부해보는 시간을 가졌다. 컨셉은 이미 알고있었다. 뭐 중간중간 데이터를 가공하는데 쓰는거겠지 라고 대충만 알고있었는데 이 대충만 아는것이 또 문제를 일으킬것같아 조금 자세히 알아보는 시간을 가졌다.인터셉터는 중간
프로그래밍을 하다보면 반복적으로 설정해 줘야하는것들이 있다. 그런것들은 손가락만 아프게하고 시간만 낭비하게 한다. 그러한 반복작업의 대표적인 예시는 dto 작성이었다. 그냥 dto쓰는것도 귀찮은데 swagger라도 붙여주려면 또 entity에서 했던것 그대로 반복해야한
nestjs를 해보기전에 express로 개발해 보신 분들은 error handling시에 throw new Error()라는 키워드가 매우 친숙할것이다. 내가 컨트롤 할 수 있는 범위 내에서 일어나는 에러를 가공할때 쓰여진다. nestjs에서도 비슷한 기능이 있을까?
예전에 개발하면서 맞닥들였던 문제중에 하나가 type alias를 사용하여 union type을 입혀 enum 대신 사용하려 한적이있었다. 자동차 연료 타입을 지정하는 것이었는데 별 문제없이 진행될줄알았다. 당시 코드를 기억해보자면 아래와 같았다.fuelType이라는