1. 개요
backend API를 만들면서 기능이 동작한다는 점, frontend에서 보안적인 이유로 진행할 수 없던 logic을 backend에서 보완했다는 점 외에 사실 매우 많은 유의사항이 존재한다.
추가적으로 알게되었던 유의사항들 중 하나는, 기능개발을 진행하면서 추후 DB나 table 등의 확장성까지 고려해야 한다는 점이다.
2. 코드는 최대한 하나의 장소에서 하나의 logic으로
backend 뿐 만 아니라 모든 코드에서도 마찬가지일 것이다.
- 코드의 확장성을 한 번 생각해보고, 이 코드가 가장 효율적인지 또 사용할 가능성이 있는지 등에 대해 고민해본다.
- 만약 확장하였을때 코드를 불필요하게 또 생성해야하고, 디렉토리를 구성할 때마다 해당 경로에 추가로 생성해야 한다면 즉시 다른 방안을 생각해본다.
- 코드를 다시 복사해서 또 다른 logic을 구성해야 하는지, 하나의 argument만 추가해서 내부 logic을 조금 가다듬어야 하는지에 대한 답은 이미 정해져 있다.
- 코드의 경로 등 의존(단순 인자의 추가로는 부족하고, 또 다른 코드를 추가해야 하는 상황)성이 높다면 이 의존성을 최소화하는 방안이 무엇일지 고민해본다.
예를 들어, 한 회사원이 자신이 다니는 동아리의 회원 수를 나타내는 API를 만든다고 가정해보자.
지금 회사원이 다니고 있는 동아리를 2개라고 할 때, 회사원은 backend API를 그에 맞게 카테고리화하거나 분류를 하는 작업이 필요할텐데, 예를 들어 지역별로 만든다고 해보자.
회사원이 서울과 수원에서 동아리를 다닌다고 하면, seoul directory와 suwon directroy에 각각 backend API를 만들 것이다.
하지만 자신이 다니는 동아리가 많아지고, 지역이 그만큼 넓어진다면 그만큼 directory도 많이 구성해야하며 이에 따른 backend API도 비례해서 늘어날 수 밖에 없다.
특히, "동아리를 다니는 회원수" 를 나타내는 logic은 지역에 상관없이 모두 동일할 것이고, 그만큼 코드 중복과 directory 공간낭비로 이어진다.
3. DB에 접근하여 data를 가져온다면 반드시 비동기 처리
sequelize를 통해 DB에 접근해서 data를 가져오거나(useQuery), data를 수정하고 update하는 상황이 발생한다(useMutation).
이럴 경우 어떠한 상황이든 반드시 비동기 처리(async-await)를 진행해준다.
일단 외부 DB에 접근하는 모든 순간은 비동기 처리를 진행해야 한다는 점을 반드시 기억하고, 그것이 읽어오든 수정하든 여하를 막론하고 무조건 해당 data를 받아올때까지 대기하거나 순차적인 처리를 진행하도록 구성한다.
지금 test를 했을때 오류가 발생하지 않았다고 해서 끝이 아니라, 위에서 처럼 확장성 - 즉 data가 대규모로 커지거나 추가적인 logic이 작성되었을때 DB를 가져오면서 오류가 발생할 수 있다는 생각을 항상 하면서 backend API 작성을 진행하는 것이 필요하다.
