Server 이전 글에서는 Path를 설계해봤었다.Path는 어디로부터 왔는 지 알기 위해 서버 출처가 필요하다.를 만족시키기 위해 서버를 관계시켜뒀는데, 이번 글에서는 해당 테이블을 설계해볼 것이다. 가장 먼저 떠오른 핵심적인 건, 서버 이름이다.사용자가 API를 등록할 때 서버 이름을 보고 해야되기 때문이다. 따라서 겹치지 않도록 고유하게 만들어둬야 한다.이제 뭐가 더 필요할까... 를 고민할 때 점점 그림이 복잡해지므로좋은 설계는 실제 현상을 기반으로 만든다. 원칙을 떠올려서 사용자 시나리오를 만들어보자.에서 서버가 필요한 부분은 여기다아래처럼 구분해두면 조회 성능에서 큰 차이가 있을 것이기 때문이다.그리고 관리자 입장에서 서버로 구분해두면 편리하다.특히 서버 도큐먼트 주소를 입력하는 부분을 어느정..

Drawing 나름 Swagger 결과 데이터를 보면서 만든 인터페이스를 소개하자면interface SwaggerPath { path: string; method: string; operationId: string; parameters?: SwaggerPathParameter[]; requests?: SwaggerPathRequest[]; responses: SwaggerPathResponse[]; tags: string[];}interface SwaggerPathParameter { name: string; required: boolean; type: string;}interface SwaggerPathRequest { contentType: ..

Scratch 좋은 설계 카테고리의 시작은 Swagger API를 이용해 인증 & 인가 서비스를 만드는 것에서 출발했다.아래는 나름 Swagger 결과 데이터를 분석해 만든 다이어그램이다.먼저 한 일은 Swagger 결과 데이터를 타입스크립트 기반으로 파싱하는 일이었는데, 결과는 뻔하지만 좋았다.구조적으로 잘 분리했기 때문에 테스트 코드나 케이스를 만드는 것도 어렵지 않았다.여기서 느꼈던 점은좋은 설계는 쉽고 정확하게 코드를 작성하게 해준다.     사실 위와 같은 구조를 만드는 것도 어렵지 않았다. 실제 팩트(fact)를 보면서 만들었기 때문이다.이런 관점에서 본다면 빠져나갈 예외 케이스도 없었다. 만족할 만한 구조가 나온 것이다.두 번째로 느낀점은좋은 설계는 실제 현상을 기반으로 만든다.    역시 ..