1. 데이터 검증, 언제 얼마나 해야할까?

목적과 대상 사용자에 따라 구분하여 검증하기

브라우저

  • 브라우저는 클라이언트의 영역
  • 사용자의 경험이 중요한 영역
  • 검증도 그에 따라서 부드럽게, 매끄럽게 잘 되어야 한다.
  • 즉 검증은 오지 사용자의 경험을 낫게 하는데에 의의를 두어야 한다.
  • 추후에 서버에서 에러를 일으킬 것을, 적절한 메시지와 타이밍에 미리 사용자에게 알려주어 더 나은 경험을 제공하는 것
  • 따라서 서버쪽 검증에 완전히 의존적일 수 밖에 없다.
  • 브라우저 단계에서 어떤 값이 실제로 유효할지에 대한 의의는 전혀 필ㅛ 없다. 데이터를 받는 서버 입장에서, 그 데이터가 적절한 클라이언트로부터 왔는지 검증할 방법이 없으므로.
    • 즉, 서버 입장에서는 요청으로부터의 데이터를 단 하나도 신뢰할 수 없다.

ref - https://elvanov.com/2414


2. RCP와 tRCP

RCP 란?

  • Remote Procedure Call 의 약자
  • 하나의 컴퓨터에서 다른 컴퓨터로 함수를 호출하는 방법
  • 전통적인 HTTP/REST API에서는 URL을 호출하고 응답을 받아왔다면, RCP에서는 함수를 호출하고 응답을 받아온다.

그러면 rcp 는 구현에 따라서 stateful 할 수도 있을 것 같다.

tRCP

  • 풀스택 애플리케이션에서 타입스크립트로 완전한 타입 세이프 API 를 만들 수 있다.
  • 서버 애플리케이션이 타입 세이프 함수 ( CURD 연산들..)가 포함된 타입 세이프 라우터를 생성하면 클라이언트 애플리케이션은 추론된 타입세이프 라우터에서 함수들을 직접 호출 할 수 있다.
  • 내부적으로는 클라이언트와 서버 간 여전히 HTTP 가 사용된다.

ref- https://aws.amazon.com/ko/compare/the-difference-between-rpc-and-rest/ ref -https://velog.io/@superlipbalm/full-stack-typescript-with-trpc-and-react


3. IDL (Interface Definition Language)로 프론트엔드 개발자가 API 설계하기

  • 소프트웨어의 인터페이스를 정의하는 명세 언어
  • 특정 언어에 국한되지 않는 방법으로 인터페이스를 정의하여, 애플리케이션들의 언어가 다르더라도 동일한 인터페이스로 통신할 수 있도록 한다.

기본적으로 제품 개발 프로세스는 아래와 같이 이루어진다.

  1. PO, PD가 기능 기획
  2. PO, PD, FE, BE가 함께 개발 스펙 픽스
  3. PD가 디자인
  4. BE가 API 설계 -> 노션 문서에 API 명세 작성 (or Swagger)
  5. FE가 4번의 스펙 확인 후 피드백

나도 사내에서 프로젝트를 진행할때 이러한 프로세스를 따랐는데, 아래와 같은 문제점들이 있었다.

  • BE가 API 설계를 픽스해야 FE가 작업을 시작 할 수 있는 부분이 있음
  • Swagger와 같은 툴을 사용하기 위해서는 API 개발이 완료되어야하니..일정상 노션문서를 사용해서 BE가 API 설계를 미리 공유하는데 이러다보니 문서가 이중으로 관리되는 문제점이 있음.
    • 또한, BE 입장에서는 문서 작성도 리소스임

그래서 위의 강남언니 사례를 보면

  1. IDL 레포지토리를 만들고,
  2. 해당 레포지토리에 FE 개발자가 인터페이스를 설계하고 IDL 언어로 정의한 후 PR을 올린다.
  3. BE,FE 가 함께 유저스토리, 인수조건을 보며 코드리뷰를 진행한다.
  4. 승인된 코드는 각 애플리케이션의 언어로 Generate 하여 메인 브랜치에 커밋된다.
  5. 각 애플리케이션에서 Generate 된 코드들을 서브모듈로 불러와 사용한다.

와 이거 생각지도 못했던 방법인데 좋네..특히나 BFF를 FE가 아니라 BE가 개발하는 환경에서 적용하면 좋을 것 같다. 🤩👍

ref -https://blog.gangnamunni.com/post/saas-why-do-frontend-developers-design-api/


토스 PO 세션

https://www.youtube.com/watch?v=Tmj1HEFnKpE

출퇴근길에 들어봤는데 재밌었다. 스타텁 다니는 사람들은 한번씩 보면 잼쓸듯
들으면서 현재 회사의 의사결정 방식에 대한 생각을 하지 않을 수가 없었다. 🥵

“잘 될 제품은 예쁘지 않아도, 노출이 적어도 잘 된다는 사실을 절실히 깨달았다…🙃”


리뷰어 활동 중간점검

우테코 코드리뷰어 활동이 바닐라 자바스크립트에서 리액트로 넘어왔다. 이제 딱 반 남았다. 리액트 미션을 시작한 후로 느낀점은, 생각보다 간단한 요구사항을 복잡한 방법으로 풀어내는 리뷰이들이 많다는 것이다. (나도 학습할 땐 그랬었음)

바닐라 자바스크립트때에도 안그랬던건 아니지만, 리액트 미션을 시작하면 리액트 API 를 사용하여 비교적 제한된 구조 내에서 문제를 간단하게 풀어낼 수 밖에 없겠거니 생각했던 것 같다.

하지만 다시 생각해보면 간단한걸 복잡하게 해결해보고, 이게 잘못된 것임을 인지할 수만 있다면 최고의 학습 경험이 될 것같다고 생각이 든다. 나도 그랬다. 전역상태로 온갖것들 다 끌어올리고 상태로 온갖 흑마술 부려보고(?) 나서 리뷰어의 지적을 받았었고, 비로소 클라이언트에서 상태를 어떻게 다뤄야할지 고민을 깊게했고 비교적 단순한 해답을 찾아서 참 개운했던 경험이 있다. (어쩌면 나도 일할때 간단한걸 복잡하게 해결하고 있는 지점들이 있지 않을까…🤔)

그런데 그러려면 리뷰어가 이를 잘 알려줘야한다. 다만 정답을 직접 알려주면 리뷰이의 시야가 좁아질 수도 있고, 내가 생각하는 정답이 또 모든 상황에서 정답이란 보장은 없다는걸 잊어서는 안된다. 따라서 직접 생각해볼 수 있도록 적절한 수준의 피드백을 줘야한다. 그렇담 리뷰어로서 리뷰이들에게 이를 어떻게 이를 전달해야할까 … 고민과 연습, 그리고 공부가 필요하다고 느끼는 요즘이다.

힘들지만 재밌는 리뷰어 활동…😎 어쩌면 내가 리뷰이들보다 얻어가는게 많을지도 모르겠군!