멘토링

[hellozo0]

모티부 이슈에 있는 내용 복붙 - 모티부 qna
안녕하세여 고민한 내용들이 좋은 질문들이네요! 답변드리겠습니다.

Q

• API를 개발하고 난 다음에 스웨거 작성에 얼마나 시간을 투자하는 지 궁금합니다.
• 스웨거 테스트를 할 때와 클라이언트 테스트를 할 때 통신 결과가 달랐던 적이 있었습니다. 그래서 API를 테스트할 때 스웨거 테스트 외에 다른 방식으로 테스트하는 방법이 있을까요?

우선 제가 스웨거를 현업에서도, 사이드에서도 안써봐서 정확한 답변드리기는 어렵네요 ㅎㅎ
사실 클라와 소통에 있어 제일 중요하지만, 개발과 더불어 제일 귀찮은게 또 API 문서 작성인데요, 저 같은 경우는 프로젝트가 작고 짧게 유지된다하면 그냥 단순히 notion 이나 github 이슈나 wiki 로도 관리해도 무방하다고 생각듭니다. 이제 프로젝트가 커지면 저는 restDocs 를 주로 사용하는 편입니다. API 문서 작성에 시간을 얼마나 투자하시냐고 질문주셨는데요, notion 이나 wiki 로 하는 경우는 길지 않지만, 잘못된 정보를 전달주면 클라에서 고생하기 때문에 하나하나 비교하며 검증하는 시간이 좀 걸리는 편이구요 (마지막 업데이트 시간이나 내역들을 정리해두는 편입니다), restDocs 로 개발할때는 하루종일 걸릴때도 있습니다 (비용이 많이 들어요) 대신 형식이 틀리게 문서가 작성될 경우는 거의 미미합니다.
따라서 스웨거도 물론 좋은 툴이지만, 말씀주신대로 통신결과가 다르고, API 테스트 바탕으로 좀 더 정확한 docs 제공이 목적이라면 restDocs 로, API 문서 비용을 줄이고 개발에 더 몰두하고싶다면 notion이나 wiki 를 선택해도 좋을것같네요. 요즘에는 postman 으로 팀 계정만들어서 api 템플릿들 구성해 공유하는 방식도 있는것같은데요 경험은 안해봤지만 이것도 추천합니다 ㅎㅎ

Q

• 테이블을 설계할 때 슈퍼 서브 타입과 원투원 타입 둘 중 보통 어떻게 설계하는 것이 좋은 지 궁금합니다.
  테이블을 처음에 설계할 때 model, designer 테이블 내에서 공통적인 항목이 많아서 슈퍼 서브 타입으로 슈퍼 타입으로 User 테이블을 만들고 서브 타입으로 Model, Designer 테이블로 만들지, 공통된 부분을 넣더라도, OneToOne 타입으로 Model, Designer 테이블로 만들지 고민을 했습니다.
  원투원 타입으로 테이블을 생성한다면 불필요한 조인이 발생한다는 단점을 보고, 슈퍼 서브 타입으로 테이블을 구성했습니다. 하지만 슈퍼 서브 타입으로 설계 했을 때 쿼리문이 복잡해지고 길어진 것은 매한가지였습니다.
  그래서 이런 상황일 때 보통 어떤 방식으로 설계하는지, 현업에서는 어떤 방식을 많이 사용하는지 궁금합니다.

음 우선 저같은 경우는 jpa 를 사용할때 관계를 명시적으로 사용하는 편은 아닙니다 ㅎㅎ 즉 db 에 fk 맺고 코드에 @OnetoOne 하면서 관계를 맺지않고, 그냥 논리적인 연결관계만 만들어두고, 코드에서 직접 그 관계를 핸들링합니다. 이렇게 하면 무결성면에서는 떨어질수있지만, 데이터 조작이 더 쉽고 의도치않은 쿼리 발생을 막을 수도 있습니다 ㅎㅎ 질문주신내용중에 불필요한 join 이 발생 이라고 해주셨는데요, 저는 rdb 를 사용하면 join 은 필연적인거고 rdb 의 최대 장점인 기능이라고 생각되어요. 다만 무작정 join 을 사용하기 보다, index 를 적절히태워서 성능적인 보장이 되면 좋겠네요. (mysql 의 index, plan 등에 대해 공부해보면 좋을것같습니다. Real MySQL 책 추천드려요). 오히려 코드상에서 쿼리문이 복잡해지고 길어지는게 더 유지보수 측면에서 손해지않을까 싶네요 ㅎㅎ 추가로, 테이블의 정규화적인 면도 고민되면 좋을것같습니다 (테이블을 분리하고 관계로 풀어갈지, 한 테이블에 넣고 운영할지)

Q

• content type이 multipart/form-data 일 때 어떤 방식이 좋은 지 궁금합니다.
  API를 설계할 때 이미지와 함께 다른 값을 받아야하는 상황이 있었습니다. 이 때 저희는 다음 2가지 방식으로 접근했습니다.
  사진은 multipart/form-data 형식으로 나머지 정보는 application/json 형식으로 동시에 받아서 처리한다.
  사진을 포함해서 모든 정보를 multipart/form-data 형식으로만 받는다.
  보통 현업에서 이미지와 함께 정보를 받을 때 어떤 식으로 하는 지 궁금합니다.

우선 multipart/form-data 가 Spring 위에서 동작할때는 메모리를 차지하게 되는데요, 그래서 되도록이면 octet-stream 타입으로의 업로드를 추천드리고싶습니다. (서버에서의 차이는 받은 사진 파일이 임시로 메모리를 차지하냐, 아니면 stream 방식으로 메모리 점유없이 동작하냐의 차이인데요, 깊게 공부해보시면 본인만의 기술적 무기가 될 수있겠네요 ㅎㅎ)
이미지 업로드와 부가정보를 한 요청에 받냐, 두 api 로 분리해받냐로 질문을 이해했습니다.
한 요청에 받게되면 form-data 가 유리할 수 있다고 생각이들긴하는데요 ㅎㅎ 다만 저는 두 api 로의 분리를 추천드리고싶습니다. (이유는 이미지 업로드에서 위 설명드린 이점이 크므로) 대신 두 요청이 분리가 된다는것은 트랜잭션 보장이 어려워서 이미지가 댕글링 포인트가 될 수 있다는 것인데요 (이미지는 올라갔으나, 부가 정보가 올라가지않아서 이미지가 주인없는 이미지가 됨) 이런 부분은 기획, UX 적으로 해결해야하는 방향이라고 생각듭니다. client 에서는 한 버튼이지만, 실제 client -> server 로는 두 api 가 호출되고, 하나가 실패하면 보상요청 (delete) 을 보내거나 retry 하는 방식 (클라이언트에서 두 요청을 보장해주는 방식)
그리고, 추가로 고민하면 좋은 부분이 이미지 업로드를 굳이 서버를 경유해야하나? 일것같네요 ㅎㅎ 클라이언트에서 바로 s3 와같은 object stroage 에 업로드하는 방향도 고민해보면 좋겠네요.
추가로 질문있는게요, 이미지 업로드에 제한은 없나요? 누군가 드라이브처럼 무한정사용하면 그 비용은 전부 모디팀에서 낼것같은데요 ㅎㅎ

Q

• 왜 S3 URL을 통해 이미지를 다운했을 때 CORS 에러가 발생하는 지 이해가 잘 안됩니다.
  클라이언트에서 S3 이미지 URL을 통해서 이미지를 다운로드 요청을 하는 로직이 있었습니다. 클라이언트에서 S3 이미지 URL을 잘 읽는 반면에 이미지 다울로드 요청을 했을 때 CORS 에러가 생겼습니다.
  해당 이슈는 Presigned url을 요청할 때 content-disposition 필드에 attach를 추가해서 이미지 다운로드가 되는 링크를 받아서 해결했습니다.
  하지만 왜 안되는 지는 찾아봐도 잘 모르겠습니다...!

content-disposition 이 attachment 라는건 이미지를 다운해 노출하는 방식일텐데요, disk 에 저장하는 방식으로 보안적으로나, 장비 관리 면에서 좋은 방법은 아닐 수 있겠네요 ㅎㅎ inline 은 브라우저에서만 display 하는 방식으로 default 로 세팅되어있군요
s3 설정을 확인해봐야할것같은데요, inline 방식이면 웹에서 s3 로 자원에 대한 접근이 일어나는것이고 이때 CORS 체크가 발생할텐데요, s3 콘솔에서 AllowedMethods, AllowedOrigins 설정을 해주었을까요? 추가로, client 측에서도 header 에 허용된 origin 을 담아보내고 있는지도 확인해볼 필요가 있겠네요 ㅎㅎ

[hellozo0]

https://github.com/daehwan2da/server-qna/issues

다른 멘토링 질문도 볼 수 있습니다