1줄 요약
이렇게 하루종일 떠들어보긴 처음이다
아침 회의
오늘은 일과가 시작하는 오전 10시부터 방금 전 오후 7시까지 밥먹는 시간 빼고 계속 회의하고 설명하면서 입을 쉴새없이 떠들어댄 날이었습니다. 먼저 오전에 팀원들과 회의를 할 때는 어제 MJ와 이야기한 것을 토대로 전달사항이 있어서 이번주 일정을 조정하는 시간을 가졌습니다.
전달사항에 관해서 이야기하자면 같이 협업하기로 한 MJ가 뒤에 있다는 걸 생각하지 못하고 단순히 제 목표를 이야기하면서 오어쓰를 집중적으로 하고 싶다고 팀원들에게 의견을 드렸습니다. 프로젝트 1주차때 바로 구현하고 싶은 마음이 커서 당장 그것부터 하자고 해서 모두가 거기에 맞춰서 오늘을 준비하고 있었던거 같았습니다. 근데 바로 일정을 바꿔버려서 조금 죄송했던거 같습니다. 담부턴 조금 신중하게 말하도록 노력해야겠습니다.
ERD와 스키마 설계 용어
MJ가 ERD와 스키마 설계를 같이해서 만나자고 했는데 그 용어에 대해서 조금 혼란스러웠습니다. 왜냐면 둘 다 같다고 생각했거든요. 그러면 굳이 나누면 ERD를 워크벤치에서 테이블 넣어서 관계설정하고 다이어그램 만든것을 ERD라고 하고 스키마 설계는 MySQL 워크벤치에서 포워드 엔지니어링하면 나오는 쿼리문들의 집합이라고 봐야하는지 생각을 했는데, 틀렸었습니다.
먼저 ERD라는 건 기획서에서 추출한 엔티티들 간의 관계에 집중해서 도식화한 것을 말하고 스키마 설계는 엔티티의 속성(키)과 관계 등을 테이블에 가깝게 수정하는 작업입니다.
둘이서 하니까 이런 용어 하나하나에도 신경쓰게 돼니 공부효과가 더 좋았던거 같습니다.
JWT?
오어쓰하면서 JWT(JSON Web Tokens)에 관한 이야기를 조금 주변에서 들었던거 같은데 그보다 다른 기능에 집중하느라 애써 무시해왔는데 이제는 배워야할 때라고 생각했습니다. 왜냐하면 MJ가 오어쓰하는 방식을 설명해주셨고 그 내부에는 JWT가 중요한 역할을 했기 때문입니다. 저도 그 임시코드와 JWT의 요청, 응답이 오고가는 것을 설명을 듣고난 후에 그렇게 구현해야겠다고 납득이 되었기 때문이빈다.
URL 네이밍할때 api를 앞에 붙이는 이유
첫번째 이유는 요처잉 Ngnix로 프록시 설정으로 80포트로 들어오는 것에 대해서 웹 프론트엔드 / 웹 백엔드 서버로 분기를 해줘야합니다. 요청경로를 가지고 분기를 많이 해주는데, 이 때 api를 앞에 붙이면서 그 경로를 기준으로 분기를 시켜주면 되기 때문입니다.
두번째 이유는 인터셉터에 관련 된건데, 인터셉터란 모든 요청에 대해서 먼저 처리해주는 건데, 특정 경로의 트래픽에 대해서 특정 처리가 가능하기 때문입니다. 이 부분은 잘 이해를 하지 못해서 인터셉터에에 관해서 먼저 공부를 더 해봐야할 것 같습니다.
한번에 Request 여러번
한번에 요청을 여러번 할 수 있는 줄 몰랐습니다. 사실 어느 사이트나 검사를 눌러서 네트워크 탭을 눌러보면 한번에 꽤 많은 요청들이 가는데 왜 그렇게 할 수 없다고 이때까지 생각해왔을까요. 어쨋든 그렇게 여러번 보낼 수도있고 필요한걸 컴포넌트화해서 한 번에 요청할 수도 있습니다.
REST 셀프 디스크립션
RESTful하게 API를 작성할 때 self-descriptive하게 작성해야 한다고 합니다. 예전에 리뷰어 분이 List를 그냥 응답하지 않고 객체에 담아서 응답해라는 리뷰를 본적이 있는것 같은데 이런 맥락에서 나온 리뷰인 것 같습니다.
self-descriptive하다는 건 스스로 모든 걸 설명할 수 있어야한다는 것입니다. 예를 들어서, 다음과 같은 JSON 데이터가 있습니다.
[
{
"name": "kyu",
"age": 12
},
{
- 반복 -
}
]
이 코드는 리스트에 객체를 담아서 그냥 응답하는 건데 이게 뭔지 충분히 설명하지 않고 있기 때문에 self-descriptive 하지 않다는 겁니다. self-descriptive 하게 작성하려면 다음과 같아야할 것입니다.
{
"human_list": [
{
"name": "kyu",
"age": 12
},
{
- 반복 -
}
]
}이렇게하면 이 리스트가 human_list라는 것을 알려주기 때문에 좀 더 RESTful 작성하려면 저런 룰도 따라야 한다는 것입니다.
하지만, MJ가 반박하신 것은경로로 이 데이터가 무엇을 말하는지 이미 충분히 유추가 가능한데 저렇게 해야하냐입니다. 예를 들어서, 이 데이터를 요청하는 URL이 GET, http://127.0.0.1/api/humans?age=12라면, 충분히 나이가 12살인 인간의 리스트를 불러온다는 것을 유추할 수 있습니다.
오늘 느낀 것
오늘은 집중도가 정말 좋았던 날인거 같습니다. 혼자였으면 분명히 이정도 집중도는 발휘되지 않았을텐데요. 협업의 장점은 특히 이런 것이 좋은것 같습니다. 서로 계속 무언가에 대해서 이해를 하고 의견을 가져야하니까요.
- 오늘 MJ와 작성한 API 문서
