GraphQL의 "삽입 가능 필드"에 대한 변호

이 글은 처음에 published on leoloso.com
이 게시물은 this comment on Reddit에 대한 나의 대답proposal to add embeddable fields to GraphQL이다.

If we want to make GraphQL good at transforming data, we need much more than string interpolation.

나는 이 점에 반대하지 않지만, 나는 명확한 답안이 하나도 없다.만약 우리가 String 삽입값을 허용한다면 우리는 Int에 대해 같은 조작을 해야 한다. 예를 들어 덧셈이나 뺄셈을 허용해야 합니까?
나는 아니라고 말할 수 있지만, 왜 그렇지 않겠는가?만약 우리가 허락한다면 이런 일이 발생할 수 있다.

query {
  service @include(if: {{ totalCredits }} - {{ usedCredits }} > 0) {
    id
  }
}

나는 여기에 나타난 이 용례를 지지하지 않는다. 나는 당연히 그것을 좋아하지 않는다.문제는 왜 우리가 String 삽입값을 허용합니까?템플릿화를 지원하기 때문에 이것은 합법적인 용례로 여겨질 수 있다.

mutation {
  comment(id: 1) {
    replyToComment(data: data) {
      id @sendEmail(
        to: "{{ parentComment.author.email }}",
        subject: "{{ author.name }} has replied to your comment",
        content: "
          <p>On {{ comment.date(format: \"d/m/Y\") }}, {{ author.name }} says:</p>
          <blockquote>{{ comment.content }}</blockquote>
          <p>Read online: {{ comment.url }}</p>
        "
      )
    }
  }
}

Programming languages are good at transforming data. Why not use application logic?

실제로 제가 최초로 제시한 규범적 특성composable fields과 composable directives은GraphQL에 메타스크립트 기능을 추가했습니다.
이것이 어떻게 유익할 수 있습니까?@translate 명령이 String에 적용된다면 this query:

query {
  posts {
    id
    title @translate(from: "en", to: "es")
  }
}

현재, 만약 한 필드가 [String], 즉 String 의 목록을 되돌려준다면, 무슨 일이 일어날까요?그리고 더 이상 사용할 수 없습니다. @translate 다른 명령을 만들어야 합니다. @translateArrays만약 그룹 중 하나의 항목만 번역해야 한다면, 모든 항목이 아니라 번역해야 합니까?그리고 변환할 키를 지정하기 위해 선택할 수 있는 매개 변수 $keys: [String] 를 추가해야 합니다.만약 키가 문자열이 아니라 숫자라면?아니면 하나의 그룹이 아니라 하나의 그룹이라면?잠깐만, 잠깐만, 잠깐만.
필드만 사용해서 데이터를 얻으면 패턴이 최종적으로 둔해질 수 있습니다.
현재 만약 우리가 필드를 조합하거나 조작할 능력이 있다면, 각각의 사용자 정의 조합을 충족시키기 위해 특수한 필드를 사용하여 모드를 오염시킬 필요가 없다.
GraphQL by PoP(내가 처음부터 디자인한GraphQL 서버)에 대해 나는 PQL라는 문법을 통해 이 점을 실현했다. 이것은GraphQL 조회의 초집합이고 지원composable fields과composable directives이다.
요소를 조합하여 모든 조합을 만족시키는 방법을 살펴보자.

게시물을 문자열로 번역: posts.title<translate(from:en,to:es)>

번역 문자열 목록: echo([hello, world, how are you today?])<forEach<translate(from:en,to:es)>>

숫자 키를 사용하여 문자열 목록의 요소만 번역: echo([hello, world, how are you today?])<advancePointerInArray(path: 0)<translate(from:en,to:es)>>

문자열 목록의 한 요소만 번역하고 키는 문자열: echo([first:hello, second:world, third:how are you today?])<advancePointerInArray(path:second)<translate(from:en,to:es)>>

변환 수조: echo([[one, two, three], [four, five, six], [seven, eight, nine]])<forEach<forEach<translate(from:en,to:es)>>>

잠깐만, 잠깐만, 잠깐만.

Embeddeble fields는 필드를 조합할 수 있는 담백한 버전으로 템플릿화하기에 충분하지만 더 높은 용례에는 적용되지 않습니다.

In your article you argue, that it is better to do this on GraphQL, but I don't understand why it would be.

나는 GraphQL이 부가 기능을 가지고 있다는 것이 가치가 있다고 생각한다.GraphQL 쿼리가 복잡한 작업을 혼자서 수행할 수 있다면 쿼리는 더욱 어려워질 수 있지만 전체 응용 프로그램은 훨씬 간단해질 것이다.
예를 들어 GraphQL을 사용하여 데이터를 검색하고 자바스크립트를 사용하여 클라이언트의 데이터를 처리한 다음에 이 데이터를 사용하여 서버에서 특정한 조작을 수행하는 전형적인 작업 흐름과 달리 메타스크립트 기능을 가진 GraphQL 조회는 클라이언트를 완전히 벗어날 수 있다.이것은 더 적은 코드 줄일 뿐만 아니라 더 적은 시스템도 관련된다.
하나의 예로, 나는 시범을 보이기 위해 조회 can send a localized newsletter 를 실현했다.
이것은 결코 억지스럽지 않다.나는 GraphQL이 데이터를 얻고 발표하는 데만 적용되는 것이 아니라고 생각한다. 왜냐하면 이 API와 클라우드 기반 서비스가 상호작용하는 현대 세계에서 데이터를 얻는 것이 무엇인지, 실행 기능이 무엇인지를 확정하기 어렵다.
예를 들어 이러한 상황은 데이터를 얻거나 발표하는 데만 한정됩니까?

이미지를 웹 사이트에 업로드할 때 S3 메모리 통

에 업로드합니다.

게시물을 작성할 때 이메일 알림

을 보냅니다.

Netlify에서 위탁 관리하는 정적 사이트에 논평을 추가할 때 우리는 새로운 구축을 촉발할 것이다

조회를 실행할 때 AWS DynamoDB 또는 Kinesis

에 추적하여 저장합니다
이러한 작업은 GraphQL 서비스에 완벽하게 통합되어 있으며, 보통 CI/CD 파이프에서 찾을 수 있다.파이프 단계가 GraphQL 조회라면 상상해 보세요.GraphQL은 데이터를 얻거나 발표하는 데 사용될 뿐만 아니라 서비스와 상호작용하는 데도 인터페이스가 될 것이다.
GraphQL에 강력한 지원을 제공하여 이러한 클라우드 기반 서비스와 상호작용을 하도록 하는 것은 우리의 API를 더욱 강하게 하고 더 많은 용례를 지원하며 미래의 새로운 수요를 위해 더욱 좋은 준비를 할 수 있을 것이라고 저는 확신합니다.

Another principle for GraphQL was coined by Lee Byron: A GraphQL server should only expose queries, that it can fulfill efficiently.

이것들은 모두 서로 모순되는 명제가 아니다.만약 구조가 양호하다면 GraphQL 서버가 반드시 성능을 떨어뜨리는 것은 아니다.예를 들어 Pop의 GraphQL은 linear complexity time on the number of types 해석 조회를 사용하기 때문에 스크래치가 생기지 않고 임의의 단계의 조합 가능한 필드를 지원한다.

The more features we add to GraphQL, the harder it becomes to ensure, that the queries are efficiently executable.

동상 1

Furthermore, your functionality requires consecutive resolver executions for one single field. This fundamentally changes how queries are executed (in a way that IMO is incompatible with the spec).

이것은 해석에 달려 있다.나는 규범에서 그 설명을 보지 못했다. 나는 그것이 나타나지 말아야 한다고 믿는다. 왜냐하면 규범은 서버가 실현해야 하는 본질이 아니라 API가 어떻게 실행되어야 하는지를 정의하는 표준이기 때문이다.

GraphQL is designed to be simple on purpose.

이러한 변경은 GraphQL 서버의 복잡성을 증가시켰고 GraphQL 조회의 추가 기능을 증가시켜 학습을 더욱 어렵게 하였다는 것에 동의합니다.
그러나 GraphQL 서비스를 더욱 강력하고 유니버설하게 하고 전체 응용 프로그램의 체계 구조를 더욱 간단하게 한다.
나에게 문제는, 이것이 가치가 있는가?