사실 프론트 단에서는 백엔드와 API 명세 관련 의견 나눌 때, 넘겨야 할 파라미터들을 리액트 단에서 문제 없이 해당 지점에서 넘길 수 있는지만 판단하면 그 외에는 딱히 더 생각할게 없는 것 같긴 하다.
근데 지금 프로젝트는 약간 학습의 성격도 좀 띄다보니 백엔드 관련 로직에 대해서 많이 듣고 같이 고민해보고 있는데, 그 과정에서 두 가지 어려움이 있었다.
-
ERD 지식
백엔드에서 API로 데이터를 제공할 때 데이터베이스의 구조에 따른 구현 난이도와 성능에 따라 어떻게 구축할 지 판단하는 듯 한데, 이러한 백쪽에서의 고민을 이해하고 같이 의견을 나누려면 데이터베이스, 즉 ERD를 전체적으로 심도 있게 파악해 둘 필요가 있겠음을 느꼈다.날 잡고 ERD 분석 좀 빡세게 해놔야겠다ㅎ
-
용어 정리
API에서 주고 받는 파라미터 중 같은 파라미터에 대해 백엔드 쪽에서 부르는 명칭과 프론트 쪽에서 부르는 명칭이 상이한 부분이 꽤 많아서, 설명을 주고 받을 때 이해하는 데 약간의 어려움이 있었다.처음 단계에서는 서로 같은 이름으로 맞추고 시작했지만, 기획을 조금씩 수정해나가면서 백엔드 쪽에서 ERD도 바뀌고 파라미터 명칭도 조금씩 바뀌는 부분이 생기면서 이런 현상이 생긴 것 같다.
그거에 맞게 리액트 코드를 수정하기에도 이제는 이미 규모가 커졌다보니 빠짐없이 수정하기에도 부담이 있는 상태이다..
현업에서는 어떻게 하려나..? 생각해봐도 결국 백엔드 쪽에서 ERD가 바뀌거나 파라미터 명칭이 새로 생기게 된다면 리액트 쪽에서 그걸 따라가서, 코드 상 바뀌어야 될 부분이 있다면 바꾸는게 최선일 것 같고, 그치만 기존에 있던 파라미터 명칭은 백 쪽에서 최대한 안 바뀌게 노력하는? 그 정도가 최선이 될 것 같다.
뭔가 이런 저런 자잘한 어려움을 겪으면서 협업에서의 경험이 풍부해지는 것 같다. 재밌따ㅎㅎ
