GraphQL에 단점이 있습니까? [닫은]

GraphQL에 대한 모든 기사는 그것이 얼마나 멋진 지 알려줄 것입니다. 그러나 단점이나 단점이 있습니까? 감사합니다.

단점 :

• 당신은 배울 필요가 GraphQL를 설정하는 방법에 대해 설명합니다. 생태계는 여전히 빠르게 진화하고 있으므로 따라 잡아야합니다.
• 클라이언트에서 쿼리를 보내야하고 문자열 만 보낼 수 있지만 더 편안하고 캐싱하려면 클라이언트 라이브러리-> 클라이언트에서 추가 코드 를 사용합니다.
• 결과를 얻기 전에 미리 스키마를 정의해야합니다 => 추가 작업
• 서버에 graphql 엔드 포인트가 있어야합니다 => 아직 모르는 새 라이브러리
• Graphql 쿼리는 단순히 REST 끝점으로 이동하는 것보다 더 많은 바이트입니다.
• 서버 는 쿼리를 구문 분석하고 매개 변수를 확인 하기 위해 더 많은 처리 를 수행해야합니다.

그러나 이것들은 이것들에 의해 반박되는 것 이상입니다.

• GraphQL은 배우기가 그렇게 어렵지 않습니다.
• 추가 코드는 몇 KB에 불과합니다.
• 스키마를 정의하면 나중에 버그를 수정하고 털이 많은 업그레이드를 지속하는 작업을 더 많이 방지 할 수 있습니다.
• 많은 사람들이 GraphQL로 전환하고 있으므로 훌륭한 도구로 풍부한 생태계가 발전하고 있습니다.
• 프로덕션에서 영구 쿼리를 사용할 때 (GraphQL 쿼리를 단순히 ID와 매개 변수로 대체) 실제로 REST보다 적은 바이트를 보냅니다.
• 들어오는 쿼리에 대한 추가 처리는 무시할 수 있습니다.
• API와 백엔드 의 깔끔한 분리를 제공하면 백엔드 개선 에서 훨씬 더 빠른 반복이 가능합니다.

GraphQL 사용을 고려하는 모든 사람에게 몇 가지 중요한 우려 사항을 발견 했으며 지금까지 주요 사항은 다음과 같습니다.

무한 깊이 쿼리 : GraphQL은 무한 깊이 쿼리를 할 수 없으므로 트리가 있고 깊이를 모르는 분기를 반환하려면 페이지 매김을 수행해야합니다.

특정 응답 구조 : GraphQL에서 응답은 쿼리의 모양과 일치하므로 매우 구체적인 구조로 응답해야하는 경우 응답의 모양을 변경하기 위해 변환 계층을 추가해야합니다.

네트워크 수준의 캐시 : 일반적으로 GraphQL이 HTTP (단일 엔드 포인트의 POST)를 통해 사용되기 때문에 네트워크 수준의 캐시가 어려워집니다. 이를 해결하는 방법은 Persisted Queries를 사용하는 것입니다.

파일 업로드 처리 : GraphQL 사양에는 파일 업로드에 관한 것이 없으며 변형은 인수에 파일을 허용하지 않습니다. 이 문제를 해결하려면 REST와 같은 다른 종류의 API를 사용하여 파일을 업로드하고 업로드 된 파일의 URL을 GraphQL 변형에 전달하거나 실행 컨텍스트에 파일을 삽입하여 파일이 리졸버 함수 내에있게됩니다.

예측할 수없는 실행 : GraphQL의 특성은 원하는 필드를 조합하여 쿼리 할 수 ​​있다는 것입니다. 그러나 이러한 유연성은 무료가 아닙니다. 성능 및 N + 1 쿼리와 같이 알아두면 좋은 몇 가지 문제가 있습니다.

Super Simple APIs : 정말 간단한 API를 노출하는 서비스가있는 경우 GraphQL은 추가 복잡성 만 추가하므로 간단한 REST API가 더 좋을 수 있습니다.

graphQL에서 볼 수있는이 가장 큰 문제는 즉 관계형 데이터베이스와 함께 사용하는 경우 조인 입니다.

1. 몇 개의 필드를 허용 / 비 허용 할 수 있다는 사실은 조인을 간단하지 않게 만듭니다. 추가 쿼리로 이어집니다.

2. 또한 graphql의 중첩 된 쿼리는 순환 쿼리로 이어지고 서버 가 중단 될 수 있습니다 . 특별한주의가 필요합니다.

3. 통화 속도 제한 이 어려워졌습니다. 이제 사용자가 한 번의 통화로 여러 쿼리를 실행할 수 있습니다.

팁 : javascript / node의 경우 facebook의 데이터 로더를 사용하여 쿼리 수를 줄입니다.

매년 점점 나아지고 있으며 현재 GraphQL 커뮤니티 는 성장하고 있으며 그 결과 이전에 다른 답변에서 강조된 많은 문제에 대한 훨씬 더 많은 솔루션이 있습니다. 그러나 여전히 기업이 모든 자원을 GraphQL에 투입하는 것을 막고 있음을 인정하기 위해 몇 가지 문제와 해결책을 나열하고 그 뒤에 해결되지 않은 문제를 나열하고 싶습니다.

• 네트워크 레벨에서 캐시 -로 브루노는 그것의 지속 된 쿼리 말했다 물론 당신이 클라이언트에 캐시 할 수 있습니다 아무도 당신이 데이터베이스 수준 또는 레디 스에 캐시 사용을 중지합니다. 그러나 물론 GraphQL에는 엔드 포인트가 하나만 있고 각 쿼리가 다르기 때문에 REST보다 이러한 유형의 캐싱을 수행하는 것이 훨씬 더 복잡합니다.
• GraphQL의 중첩 된 쿼리는 순환 쿼리로 이어지고 서버에 충돌을 일으킬 수 있습니다. 더 이상 다양한 솔루션에서 문제가되지 않습니다. 그들 중 일부는 여기 에 나열되어 있습니다.
• 파일 업로드 처리 - 우리는 한 이미 많은 의 솔루션을 그것을 위해

그러나 단점으로 간주 될 수있는 몇 가지 사례가 더 있습니다.

• 상용구 과도 (예를 들어 새로운 쿼리를 생성하려면 스키마, 해석기 및 해석기 내부를 정의하여 GraphQL 내부에서 데이터 및 필드를 해결하는 방법을 명시 적으로 지정해야합니다. 클라이언트 측에서 이 데이터)
• 오류 처리 -REST와의 비교와 더 관련이 있다고 말해야합니다. 여기서 아폴로로 가능하지만 동시에 REST보다 훨씬 복잡합니다.
• 인증 및 권한 부여 -하지만 내가 말했듯이 커뮤니티는 빠른 속도로 증가하고 있으며 이미이 목표에 대한 몇 가지 솔루션 이 있습니다.

요약하자면 GraphQL은 특정 목표를위한 도구 일 뿐이며 모든 문제에 대한 은총이 아니며 물론 REST를 대체하는 것도 아닙니다.

단일 엔드 포인트를 가지고 모든 데이터를 노출하는 것은 정말 좋습니다. GraphQL에서 고려해야 할 사항은 다음과 같습니다.

1. 파일 다운로드 / 업로드 구현이 까다 로움 (큰 파일의 경우 문자열로 변환하는 것이 최선의 선택이 아닐 수 있음)
2. 프런트 엔드와 백엔드 모두에서 많은 상용구 및 스키마 코드.
3. GraphQL 사양에 제공된 페이지 매김을 따르고 지원합니다.
4. 필드 순서에 대한 사용자 지정 순서 및 우선 순위 논리를 허용합니다. 사용자 데이터와 관련 그룹 및 역할을 가져 오는 경우의 예입니다. 사용자는 사용자 이름, 그룹 이름 또는 역할 이름을 기준으로 데이터를 다중 정렬 할 수 있습니다.
5. 인증 및 권한 부여는 백엔드 프레임 워크에 따라 다릅니다.
6. 각 graphql 명령에 대해 단일 쿼리를 실행하는 백엔드 최적화 및 데이터베이스 지원이 까다로울 수 있습니다.

또한 구현 후 프로를 고려해야합니다.

1. 새 항목을 지원하고 기존 동작을 업데이트하는 데 매우 유연합니다.

2. 인수 및 사용자 지정 순서를 사용하여 쉽게 조건을 추가 할 수 있습니다.

3. 많은 사용자 정의 필터를 사용하고 사용자가 ID, 이름 등을 인수로 갖고 필터링을 수행 할 수있는 예를 들어 생성해야하는 모든 작업을 제거합니다. 또한 필터는 사용자의 그룹에도 적용 할 수 있습니다.

4. 모든 GraphQL 쿼리 및 변형이 포함 된 파일을 생성하여 API를 쉽게 테스트 할 수 있습니다.
5. 변형은 개념을 이해하면 간단하고 구현하기 쉽습니다.
6. 여러 깊이의 데이터를 가져 오는 강력한 방법입니다.
7. Voyager 및 GraphiQL UI 또는 Playground를 지원하여 쉽게보고 사용할 수 있습니다.
8. 유효한 설명 방법으로 스키마를 정의하는 동안 문서화가 용이합니다.

지금은 graphql이 백엔드 아키텍처의 일부 여야한다고 생각합니다. 파일 업로드를 위해 여전히 일반 API에 도달했습니다.