GraphQL을 사용하면 비즈니스 도메인을 그래프로 모델링 할 수 있습니다.
그래프는 근본적인 프로세스에 대한 인간의 뇌 구조와, 언어적인 설명과 비슷하기 때문에 많은 실제 세계의 현상을 모델링하는 강력한 도구입니다. GraphQL을 사용하면 스키마를 정의하여 비즈니스 도메인을 그래프로 모델링할 수 있습니다. 스키마 내에서 서로 다른 타입의 노드와 노드가 서로 연결, 연관되는 방식을 정의할 수 있습니다. 클라이언트에서는 다른 타입을 참조하는 타입
과 같은 객체 지향 프로그래밍과 비슷한 패턴을 만듭니다. 서버에서는 GraphQL이 인터페이스만 정의하므로, 모든 (기존 혹은 새로운)백엔드에서 자유롭게 사용할 수 있습니다.
네이밍은 직관적인 API를 작성하는데 있어서 어렵지만 중요한 부분입니다.
GraphQL 스키마를 팀과 사용자를 위한 표현적인 Shared Language
로 생각해보세요. 좋은 스키마를 설계하려면, 당신의 비즈니스를 설명할 때 사용하는 일반적인 말들을 살펴보세요. 예를 들어, 일반적인 글로 이메일 앱을 설명한다면,
네이밍은 직관적인 API를 개발하는데 있어서 어렵지만 중요한 부분이므로 당신의 도메인과 사용자 문제에 무엇이 합당한지 신중하게 생각해보세요. GraphQL 스키마에서 노드와 관계에 대해 직관적이고 내구성있는 이름을 선택해야하기 때문에, 당신의 팀은 이러한 비즈니스 도메인 규칙에 대한 이해와 합의를 공유해야합니다. 당신의 실행하게될 쿼리를 생각해보세요.
내 모든 계정에 대해 받은 편지함에 읽지 않은 이메일 수(unreadEmailCount
) 가져오기
{ accounts { inbox { unreadEmailCount } } }
메인 계정의 상위 20개 메일에 대한 previewInfo
가져오기
{ mainAccount { drafts(first: 20) { ...previewInfo } } } fragment previewInfo on Email { subject bodyPreviewSentence }
비즈니스 로직 레이어는 비즈니스 도메인 규칙을 적용하기 위한 단일 소스로 작동해야합니다.
실제 비즈니스 로직은 어디에 정의해야할까요? 유효성검사 및 권한 확인은 어디서 수행해야 할까요? 정답은 전용 비즈니스 로직 레이어 내부입니다. 비즈니스 로직 계층은 비즈니스 도메인 규칙을 적용하기위한 단일 소스로 작동해야합니다.
위의 다이어그램에서 시스템에 대한 모든 진입점(REST, GraphQL 및 RPC)은 모두 동일한 규칙의 유효성검사, 권한부여, 에러핸들링으로 처리됩니다.
클라이언트가 레거시 데이터베이스 스키마를 미러링하는 것이 아닌, 데이터를 사용하는 방식을 설명하는 GraphQL 스키마를 작성하는 것이 좋습니다.
경우에 따라, 클라이언트가 데이터를 사용하는 방식을 완벽하게 반영하지 않는 기존 데이터 소스로 작업하는 경우가 있습니다. 이 경우 레거시 데이터베이스 스키마를 미러링하는 대신 클라이언트가 데이터를 사용하는 방식을 설명하는 GraphQL 스키마를 작성하는 것이 좋습니다.
how
보다는 what
을 표현하도록 GraphQL 스키마를 작성하세요. 그러면, 기존 클라이언트와의 인터페이스를 유지한채로 구현 세부사항을 추가할 수 있습니다.
검증 및 피드백을 보다 자주 받으세요.
한 번에 전체 비즈니스 도메인을 모델링하지 말고, 한 번에 하나의 시나리오에 필요한 부분만 스키마를 만드세요. 점진적으로 스키마를 확장함으로써 올바른 솔루션을 구축하기 위해 검증과 피드백을 보다 자주 받을 수 있습니다.