🥸 서론 현재 진행 중인 Ticketing 프로젝트는 시스템이 분리되어있다는 가정 하에 진행된 프로젝트입니다. 여기서 결제시스템에서는 어떤 유저가 결제했는지에 대한 정보가 있어야 합니다. 처음 설계 당시에는 유저 PK 값을 넣어서 사용하려 했지만, 몇 가지 문제가 있어서 대체 유니크키 생성을 결정하게 되었고, 그 내용을 정리해보려 합니다. 😎 본론 기존 ERD 구조입니다. 여기서 Payment 에서 User의 pk 값을 가지고 있죠. 고민의 시작인 API의 간단한 Sequence Diagram 입니다. 여기서 결제 목록 요청을 할 때 각 유저의 고유한 값을 Payment에서 가지고 있어야 유저의 결제 목록을 응답해줄 수 있습니다. 여기서 기존엔 User의 PK를 사용했는데, 왜 고민했는지 Email, U..
😏 서론 현재 제가 진행 중인 토이 프로젝트는 '영화예매' 주제로 진행 중에 있습니다. 테이블 설계 이후 구현 단계에서 다른 테이블에 중복 컬럼을 왜 추가하게 됐는지 정리해보려 합니다. (많이 History 느낌의 글입니다.) 🥹 본론 현재 프로젝트 상황 패키지 시스템 구조는 아래와 같습니다. 나중에 MSA 구조로 분리하기 위해 현재는 패키지만 분리해둔 상태입니다. ERD 영화 서비스에선 5개의 테이블 결제 서비스와 유저 서비스에선 각각 1개의 테이블이 있는 구조입니다. 요구사항 분석 회원 결제목록 조회 로그인된 사용자의 정보를 이용해서 결제 목록을 얻어온다. 결제목록은 영화제목, 금액, 결제상태가 존재한다. 요구사항을 위해서는? 결제목록을 가져오는 요구사항은, 현재 설계된 모든 서비스를 거치게 됩니다...
이번 프로젝트를 시작하기에 앞서 graphql에 접하게 되었다. 하는방법이나 연습은 Nomad Coders와 howtographql를 통해 쉽게 접할 수 있었다. 지금까지 REST API로 작업하면서 느꼈던 불편함들을 graphql을 통해 해소할 수 있었으며, 코드의 간결함, 보기쉽고 백과 프론트가 주고받기 쉬움 등 여러 장점이 있었다. 내가 느낀 장점과 해외사이트에서 소개한 장점들을 설명하면서 Graphql이 왜 주목을 받는지 정리를 해볼 예정이다. 일단 'Graphql'은 Fackbook에서 만든 오픈소스 쿼리언어입니다. 현재 전 세계에 있는 대기업 및 개인커뮤니티에서 관리를 하며 빠른 성장세를 유지하고 있습니다. 오랫동안 유지해오던 REST API의 대안으로 나온 Graphql이 이토록 무서운 성장..
