🤔 GraphQL은 사용자마다 달라야 할까요?

GraphQL은 특정 출처에서 데이터를 가져오기 위한 인터페이스이며, GraphQL 사양은 해당 인터페이스의 요건을 정의합니다. 이러한 요건이 충족되는 한, GraphQL은 구현 방식을 가리지 않습니다. GraphQL 서버는 JavaScript의 Promise를 사용하거나, Golang 기반의 동시성 아키텍처를 활용하거나, Excel 파일에 매핑하거나, 그 외 다양한 방식으로 구현될 수 있으며, 이 모든 방식이 GraphQL 사양의 유효한 구현이 될 수 있습니다.

서버의 엔진이 어떻게 구현되는지는 GraphQL 요청의 성공적인 실행에 있어 중요하지 않습니다. 클라이언트와 서버 간의 상호작용은 항상 동일하며, 정의된 구문을 사용하여 GraphQL 쿼리를 제출하고 JSON 형식으로 해당 응답을 받는 방식으로 이루어집니다.

여기서 구현이 중요하지 않다고 말할 때, 이는 API 사용자의 관점에서 이야기하는 것입니다. 사용자는 단순히 서버에서 데이터를 가져오려고 할 뿐이며, 반환된 데이터가 어떻게 생성되었는지에는 관심이 없습니다.

하지만 API를 담당하는 서버 사이드 개발자에게는 상황이 달라집니다. 구현의 세부 사항은 매우 중요합니다. GraphQL API를 PHP로 코딩한다면, PHP가 제공하는 기능을 최대한 활용하면서 가능한 한 효율적으로 API를 처리하고, 가능한 한 우아한 아키텍처 설계를 갖출 수 있도록 최선을 다할 것입니다.

이로 인해 API를 보호해야 하는 필요성과, API를 담당하는 개발자들이 기대하는 기능(재귀 코드를 실행하는 능력 등, 기반 언어가 지원하는 기능을 빼앗기고 싶지 않은 것) 사이에서 이해관계의 충돌이 발생할 수 있습니다.

이 충돌은 이슈 #929: Allow recursive references in fragments에서 명확하게 드러났습니다. 이 이슈는 GraphQL이 fragment에서의 재귀를 금지해서는 안 된다고 주장합니다.

GraphQL 워킹 그룹의 과거 밋업에서, 이 이슈를 제기한 개발자 Roman은 사양이 부과하는 제한에 대한 반대 의견을 다음과 같이 표명했습니다.

저는 서버 사이드 개발자이며, 사양이 서버 사이드 실행에 대해 너무 많이 다루고 있는 반면, 클라이언트가 무엇을 전달받기를 원하는지에 집중해야 한다고 생각합니다——어떻게가 아니라

fragment에서의 재귀를 금지하는 규칙은 공개 API의 보안을 유지한다는 전제로 정당화되어 왔습니다. 결국 GraphQL은 Facebook이 공개용 애플리케이션에 데이터를 제공하기 위해 만든 것이며, 사용자가 API 설계의 결함을 악용하여 서비스를 중단시킬 수 있어서는 안 됩니다.

GraphQL 창시자 Lee Byron은 세 가지 주요 우려 사항을 표명했습니다.

무한 재귀；제한은 사양만의 문제가 아닙니다——언제 어떻게 중지해야 하는가

데이터 검증；동일한 값을 여러 번 반환하는 경우, 데이터에서 어떻게 표현되는가. 이상적으로는 순환을 감지하고 즉시 중지하고 싶지만, 일부 서버는 이를 감지하지 못하고 문제를 감지하여 중지하기 전에 여러 번 루프를 돌 수 있습니다

이것을 갖지 않는 것의 비용은 무엇인가；이러한 문제들을 정당화하는가？그렇지 않습니다；쿼리에서 깊이 수준 수를 지정하는 것은 항상 가능합니다——그것은 사실상 GraphQL에서 이를 처리했을 경우 수행할 것의 탈설탕화 버전입니다

각자의 입장에서 보면 Roman과 Lee 모두 옳다고 할 수 있습니다. Lee Byron은 공개 GraphQL API의 보안을 걱정합니다. 재귀적인 fragment를 피하는 것은 악의적인 행위자가 쿼리에서 끝없는 순환 루프를 실행하여 시스템을 중단시키는 것을 방지하고, 팀이 의도치 않게 시스템을 중단시키는 쿼리를 공개하는 「셀프 DDoS」의 가능성을 없애기 위해 정당화됩니다.

반면 Roman은 GraphQL API를 만들기 위한 자신의 능력에 부과되는 제한을 우려합니다. Roman이 API의 유일한 소비자인 경우(즉, 사용자에게 노출되지 않는 프라이빗 API인 경우), 또는 서버가 순환 사이클을 감지하고 중지하는 능력을 갖추고 있는 경우, GraphQL의 제한은 해롭고 정당화될 수 없다고 생각합니다.

논의의 핵심은 재귀적인 fragment를 허용해야 하는지 여부가 아니라, 더 근본적인 문제입니다. GraphQL의 대상은 누구인가? 단일 그룹이 아니라면, 단일 API 사양이 모든 다양한 이해관계자들의 요건을 충족할 수 있는가? 그리고 충돌을 막을 수 없다면, 적어도 어떤 방식으로 완화할 수 있는가?

이러한 질문들을 살펴보겠습니다.

​

GraphQL의 대상은 누구인가?

GraphQL은 다양한 종류의 이해관계자들에 의해 사용되며, 그 중에는 다음과 같은 그룹이 포함됩니다.

1. API 사용자: 어떤 이유로든 GraphQL 엔드포인트에서 데이터를 소비하는 사람들. 예를 들어, GitHub의 공개 GraphQL API의 API 사용자가 되어 GitHub 저장소에 관한 데이터를 가져올 수 있습니다.

2. 클라이언트 사이드 개발자: GraphQL 엔드포인트를 기반으로 하는 클라이언트 사이드 애플리케이션을 만드는 사람들. 예를 들어, Gatsby로 사이트를 구축하는 개발자들은 GraphQL을 사용하여 사이트의 콘텐츠를 가져옵니다.

3. 백엔드 개발자: GraphQL API의 리졸버를 만드는 사람들.

또한, GraphQL API는 공개 또는 비공개일 수 있다는 점에 주목해야 합니다.

공개 API: GraphQL 엔드포인트에 누구나 접근할 수 있으므로, 악의적인 행위자의 공격을 피하기 위한 보안 조치를 강구해야 합니다.

비공개 API: 의도된 행위자만이 API에 접근할 수 있으므로, 본질적인 보안 위험이 없으며, 셀프 DDoS도 적절한 코딩 관행으로 쉽게 피할 수 있습니다.

​

단일 API 사양이 모든 이해관계자의 요건을 충족할 수 있는가?

Roman이 제기한 이슈는 다음과 같이 해석할 수 있습니다. "내 GraphQL API가 비공개이고, 내가 하는 일을 정확히 알고 있다면(코드가 예상대로 작동하고 실행이 중단되지 않는다는 100%의 확신이 있다면), 왜 fragment에서 재귀를 사용할 수 없는가?"

이러한 상황의 예는 정적 사이트를 구축하기 위해 GraphQL 기반 프레임워크(Gatsby, Next.js 또는 RedwoodJS 등)를 사용할 때 발생합니다. GraphQL API는 종종 비공개이며, 실수로 애플리케이션을 DDoS하여 불이익을 당할 수 없습니다(최악의 경우 개발 환경 또는 스테이징 환경에서 정적 사이트를 구축할 때 충돌이 발생할 뿐입니다).

위 설정을 사용하는 개발자들이, GraphQL 사양이 자신들의 설정에는 아무런 부정적인 결과가 없는 유익한 기능을 사용하지 못하게 금지하는 이유가 무엇인지 의아하게 여기는 것은 당연합니다.

결론적으로, 재귀적인 fragment를 금지함으로써 GraphQL 사양은 GraphQL의 모든 잠재적 용도 중 일부에만 적용되는 보안 조치를 안전을 위해 부과하고 있으며, 모든 용도에 적용되는 것은 아닙니다.

​

GraphQL 사양은 모든 이해관계자를 더 잘 만족시킬 수 있는가?

서로 다른 이해관계자들이 서로 다른 요건을 가지고 있다면, GraphQL 사양은 어떻게 모든 사람을 만족시킬 수 있을까요? (사양을 포크하여 특정 대상을 위한 맞춤형 버전을 만드는 것은 피하고자 하는 생각입니다.)

두 가지 아이디어를 살펴보겠습니다. 첫 번째는 사양 기여 프로세스를 거쳐야 하지만, 두 번째는 그렇지 않습니다.

​

GraphQL 사양 수준에서의 feature-toggle

취할 수 있는 한 가지 방법은 사양이 규칙을 「강제」하는 것이 아니라 「제안」하는 것입니다. 이 경우, fragment에서의 재귀를 금지하는 규칙은 강력히 권고되지만, 해당 기능은 여전히 허용됩니다.

그런데 이 해결책은 재귀적인 fragment의 기본 상태를 「필수」에서 「선택」으로 변경하게 되어, 두 가지 부정적인 결과를 초래합니다.

• API가 기본적으로 안전하지 않게 됩니다(Lee Byron이 피하고 싶은 시나리오)
• 금지되었던 쿼리가 허용되므로 호환성 파괴 변경이 발생합니다

따라서 옵션을 반전시키는 것이 더 낫습니다. fragment에서의 재귀는 기본적으로 여전히 금지되지만, 이 동작을 비활성화하는 feature-flag를 전환할 가능성을 제공합니다. 기능을 명시적으로 비활성화해야 하므로, 자신이 무엇을 하고 있는지 이해하는 관리자만이 이를 수행할 것입니다.

이 기능은 특정 설정 하에서 가장 가치 있으므로, GraphQL 서버와 프레임워크는 설정을 제공할지 여부, 어떻게, 언제 제공할지를 결정할 수 있습니다. 예를 들어, Gatsby는 정적 사이트를 만들 때 UI를 통해 옵션을 눈에 띄게 표시하고, 그 외의 경우에는 숨길 수 있습니다.

일반적인 아이디어는 GraphQL 사양이 「활성화되어 있지만 선택적인 기능」을 지원하는 것입니다. 이러한 기능들은 설정을 통해 활성화/비활성화할 수 있으며, 기본 상태는 사양에서 이미 가지고 있는 상태입니다.

재귀적인 fragment 금지가 그 중 하나가 될 것이며, Map 타입과 같은 다른 기능들도 있을 수 있습니다. Map 타입은 Lee Byron에 의해 사양에 수용되지 않았습니다. 그 이유는:

Map 타입과 키/값 쌍의 리스트 사이에는 상당한 트레이드오프가 있습니다. 한 가지 문제는 컬렉션의 페이지네이션입니다. 값의 리스트는 명확한 페이지네이션 규칙을 가질 수 있지만, 순서가 없는 키-값 쌍을 가지는 경우가 많은 Map은 페이지네이션이 훨씬 어렵습니다.

또 다른 문제는 사용 방식입니다. 대부분의 경우 Map은 값의 한 필드가 인덱싱되는 API에서 사용되는데, 제 생각에는 인덱싱은 스토리지의 문제이자 클라이언트 캐싱의 문제이지 전송의 문제가 아니기 때문에 이것은 API 안티패턴입니다. 이 안티패턴이 우려됩니다. API에서 Map의 좋은 사용 사례도 있지만, 일반적인 사용이 이러한 안티패턴을 위한 것이 될까봐 걱정되므로 신중하게 진행할 것을 제안합니다.

Lee Byron은 해당 기능이 안티패턴으로 사용될 것에 대한 우려를 표명했습니다. 그러나 좋은 사용 사례도 있다는 것을 인정했습니다. 따라서 이슈가 커뮤니티에서 많은 지지를 받은 것을 감안하여(150개 이상의 👍), 개발자들에게 Map 타입을 스키마에 추가하는 것을 명시적으로 활성화하고 그 결과를 처리하는 옵션을 제공할 수 있습니다.

​

GraphQL 서버에 의한 feature-toggle

위의 제안이 GraphQL 사양에 너무 위험하다는 이유로 지지를 받지 못한다면, 대안은 GraphQL 서버 수준에서 구현하는 것입니다. GraphQL 서버는 fragment에서의 재귀를 비활성화하는 커스텀 기능을 제공할 수 있습니다.

아이디어를 일반화하면, GraphQL 서버는 사양의 특정 기능을 비활성화하고, 사양에 없는 기능을 활성화하는 것을 제공할 수 있습니다. 이 동작이 놀라움을 주지 않도록 하기 위해, 서버는 기본 상태가 사양에서 요구하는 것임을 확인하고, API 관리자는 기능을 전환하는 것의 결과를 충분히 인식하고 있어야 합니다. (이것이 Gato GraphQL이 「innovative features」를 위해 채택한 전략입니다.)

​

마무리

GraphQL이 점점 더 인기를 얻으면서, 새로운 기능을 지원하는 새로운 프레임워크들이 이를 스택의 일부로 삼았으며, 새로운 이해관계자들(그리고 그들의 새로운 유형들)이 참여하게 되었습니다. 따라서 원래 Facebook이 애플리케이션이 서버에서 데이터를 가져오는 방법을 정의하기 위해 만든 사양은 점점 더 많은 사용 사례에 대응해야 합니다.

재귀적인 fragment의 경우처럼, 한 이해관계자 그룹이 다른 이해관계자들에게는 역효과를 내거나 심지어 해로운 기능을 필요로 하는 경우, 충돌이 발생하는 것은 피할 수 없습니다. 상황을 개선하고, 불만족스러운 이해관계자들이 GraphQL에 실망하지 않도록 하기 위해 무엇을 할 수 있을까요?

저는 사양이 기능을 「비활성화」할 기회를 제공하여, 자신이 하는 일을 이해하는 관리자가 자신의 요건을 충족시키기 위해 일부 제한을 없앨 수 있도록 해야 한다고 주장했습니다. 다만, 저 자신은 이 해결책에 동의하지 않지만, 이 논의가 이루어져야 하기 때문에 그럼에도 불구하고 세상에 내놓습니다. 이 아이디어는 논란의 여지가 있으므로, 더 나은 대안은 GraphQL 서버가 커스텀 기능을 통해 이 동작을 제공하는 것입니다. 그것들은 명시적으로 활성화되어야 합니다.