GraphQL이 마이크로서비스에 완벽한 이유

잘 설계된 마이크로서비스 아키텍처는 놀라운 것입니다. 각 서비스가 고유한 특정 도메인을 담당하고 독립적으로 배포할 수 있으면 백엔드 팀에 탁월한 유연성과 생산성을 제공할 수 있습니다. 그러나 모놀리식 백엔드 대신 마이크로서비스를 선택하기로 한 결정을 포함하여 비용 없이 모든 이점을 얻을 수 있는 결정은 거의 없습니다.

백엔드를 GraphQL로 마이그레이션하기 전에, 특히 여러 서비스의 데이터를 사용하는 보기를 만들어야 할 때 클라이언트 측 네트워킹 코드에 부과되는 추가적인 복잡성이 있었습니다.

예를 들어 우리 애플리케이션에는 다음과 같은 "약속 목록"보기가 있습니다.



모놀리식 아키텍처에서 이 페이지의 네트워킹 코드는 사소할 수 있습니다. 제공자, 환자 및 진료소 세부 정보 없이 약속을 보는 것은 매우 드문 일이므로 약속 쿼리에서 해당 테이블을 조인하고 매번 반환하는 것이 좋습니다.

예를 들어:

[MONOLITH]: /companies/id/appointments

{ result: [Appointment] } <--- joined with provider/patient info

그러나 Appointment Service는 공급자 및 환자 데이터에 액세스할 수 없기 때문에 마이크로 서비스 아키텍처에서는 이 JOIN이 불가능했습니다.

우리의 클라이언트 애플리케이션은 이제 필요한 모든 데이터를 반환하는 하나의 리소스를 쿼리하는 대신 4개의 서로 다른 엔드포인트를 통해 3개의 서로 다른 서비스를 쿼리해야 했습니다. 또한 클라이언트 애플리케이션은 초기 예약 쿼리를 ​​로드할 때까지 필요한 공급자, 환자 및 클리닉의 ID에 액세스할 수 없었습니다!

따라서 클라이언트 측 네트워킹 로직은 다음과 같이 생겼습니다.

- [APPOINTMENT SERVICE] - GET /companies/id/appointments

.. wait for data ...

{ result: [Appointment] }

THEN:
- [PATIENT SERVICE] - GET /patients/id x 5
- [COMPANY SERVICE] - GET /clinics/id x 5
- [COMPANY SERVICE] - GET /providers/id x 2

이상적이지 않습니다! 요청은 빨랐지만 나머지 관련 세부 정보를 가져오기 전에 초기 약속 요청이 완료될 때까지 기다려야 했기 때문에 모놀리식 버전보다 거의 두 배나 느렸습니다.

구조를 위한 GraphQL

우리는 한동안 이러한 제한 사항을 해결하기 위해 노력했지만 결국 무언가를 제공해야 한다는 것을 깨달았습니다. 백엔드 팀이 그토록 좋아했던 마이크로서비스 인프라는 프런트엔드 및 모바일 팀의 개발자 경험을 극도로 실망스럽게 만들었습니다. 우리는 해결책이 필요했고 신속하게 해결책이 필요했습니다.

운 좋게도 GraphQL 생태계에는 우리 문제에 대한 완벽한 솔루션인 Apollo Federation이라는 완전히 새로운 혁신이 있었습니다.



Apollo Federation은 각 마이크로 서비스가 자체 "하위 그래프"를 관리하는 동시에 클라이언트 애플리케이션에서 해당 복잡성을 추상화하도록 허용했습니다. 우리의 모든 하위 그래프는 GraphQL 게이트웨이에서 함께 연결되어 단일 끝점을 통해 쉽게 액세스할 수 있는 하나의 원활한 연합 그래프를 생성했습니다.

회사 약속 목록에 대한 새로운 요청은 다음과 같습니다.

- [GRAPHQL GATEWAY] - POST /graphql

query {
  companyAppointments { <--- [APPOINTMENT]
    startTime
    patient { <--- [PATIENT]
      firstName
      lastName
    }
    provider { <--- [COMPANY]
      firstName
      lastName
    }
    clinic { <--- [COMPANY]
      clinicName
      lastName
    }
}

고객은 쿼리 중인 데이터를 해결하는 백엔드 서비스를 알 필요가 없었고 이 보기를 완료하기 위해 한 번만 요청하면 되었습니다. 이 새로운 쿼리는 또한 다음과 같은 이유로 훨씬 더 효율적이었습니다.

GraphQL은 클라이언트가 요청한 특정 필드만 반환하므로 페이로드가 훨씬 작아집니다.

게이트웨이는 클라이언트에 응답하기 전에 서비스 간 통신을 통해 필요한 모든 데이터를 수집할 수 있습니다(후속 요청의 필요성 제거)

GraphQL Federation 덕분에 우리는 케이크를 먹고 먹을 수 있었습니다! 백엔드 팀은 마이크로서비스가 제공하는 모든 이점으로 개발을 계속할 수 있었고 프런트엔드 및 모바일 팀은 GraphQL의 유연성으로 더욱 효율적이 되었습니다.

우리는 Federated GraphQL로의 마이그레이션 결과에 매우 만족했으며 마이크로서비스는 REST와 함께 좋을 수 있지만 GraphQL과 함께 더 좋습니다!