면접질문으로 받았던 여러가지 질문 중 사용해보지 못했다. 라고 대답했던 몇가지 중 하나.
유효성 검사를 혹시 해보셨나요?
해보지 못했다, 그런데 계속 지켜보고는 있었다.
나는 npm을 가끔씩 둘러보는 편인데, 사람들이 뭘 많이 쓰는가에 대해서 찾아볼 때가 있다.
그럴 때 보였던 라이브러리중 joi 라는 것이 있었고,
도대체 어떤 역할을 하길래 이렇게 많이 쓰는지에 대한 궁금증이 생겼다.
그 당시에는 유효성 검사를 조금 더 쉽게 도와주는 역할을 하는 라이브러리라고 적혀있는 것을 봤다.
그래도 나는 사용할 엄두가 안났다.
프로젝트 기간은 한계가 있었고, 상당한 분량의 코드가 필요한 것 같아서 도입을 하지 못했다.
도대체 왜 써야하는데?
그리고 현재로 돌아와서, 미니프로젝트에는 사용을 해봐야겠다. 라는 마음으로
Nest 공식 문서에 추천하고 있는 라이브러리를 다운받고, 사용을 하면서 뭔가 의문이 들었다.
나는 REST API가 아닌, GrahpQL를 사용하고 있는데
그래프큐엘에서는 자체적으로 타입을 검증해주는 시스템이 존재한다.
입력값을 문자열로 제한을 해두면 자체적으로 GraphQL이 알아서 문자열이 아니면 서버까지 가지도 않고, 그 전에 처리를 해준다.
그럼 또 다시 의문이 든다.
왜씀?
그래서 gql을 사용하고 계신 개발자분께 질문을 했다.
자체적으로 해결해주는데, 도대체 유효성 검사가 필요한가요?
서버개발자는 그 누구도 믿으면 안된다.
인간의 어두움은 끝이 없기 때문에 그것을 방지하고자
유효성 검사를 무조건 해야한다는 것이 질문의 답변이였다.
비밀번호가 공백인데, 값이 나오는 기현상을 볼 수 있다.
왜냐하면 공백은 문자열이기 때문에(....) 저장이 된다.
물론 이러한 작업은 프론트(클라이언트)단에서 해결을 해줘야한다고 생각한다.
왜냐하면 이것 또한 서버에 API를 호출하는 것이기에 비용이 발생하니까.
정규식을 쓰지 않아도 되는 편의성
보통 이메일같은 것을 검증할 때는, 정규식을 많이 사용하여 작성을 한다.
하지만 이렇게 라이브러리를 통하여 데코레이터를 붙이는 것으로 간단하게 처리를 할 수 있는 장점이 있는데
이메일 외에도 수많은 옵션이 존재해서, 사용해보면 상당히 편할 것이라는 생각이 들었다.
라이브러리 깃허브 => https://github.com/typestack/class-validator
서버개발자라는 포지션은, 결국 끝없는 창이 날라오는 환경 속에서 든든하게 방패로 막아주는 포지션이라는 생각이 들었다.
끝없는 검증을 통하여 서버에 영향이 가지않게 하는 것.... 참 재밌기도 하고 멋진 포지션같다.
이런 문제가 있다는 것을 알았으니, DB injection에 대해서 알아봐가지고
프로시저를 적용시키는 것도 좀 찾아봐야 할 것 같다.
그런데 여기서도 약간의 의문이 존재한다.
입력값에 DTO를 적용해놓고, 한 개의 값마다 검증하는 것을 추가해놨는데
DTO 그 자체에도 커스텀 파이프를 만들어서 검증을 해야하는가?에 대한 고민은 조금 더 찾아봐야할 것 같다.
끝
