간단한 방법으로 그림을 만들거나: 아폴로를 사용하지 마라

GraphQL의 기본 원리는 매우 간단하다.그럼에도 불구하고 바쁜 기차와 로켓 속도 생태계 투기는 현실 세계에서 GraphQL API를 구축하는 것은 까다로운 균형 동작일 수 있으며 복잡한 상호작용을 1마일 높이에 쌓아야 한다는 것을 의미하며 모든 사람들이 완전히 이해하지 못한다.
이 중 약 90퍼센트는 Apollo이라는 투기회사가 건설하고 대대적으로 보급한 것이다.아폴로는 자신을'데이터 그래픽 플랫폼'으로 묘사하고 자신이 묘사한'업계 표준GraphQL 실현'을 구축했다.
불행하게도, 나는 그들의 플랫폼이 매우 좋다고 확신하지만, 만약 당신이 새로운GraphQL API를 세우고 있다면, 당신은 Apollo로부터 시작해서는 안 된다.이것은 나중에 틀림없이 쓸모가 있을 것이다. 그러나 첫날, 이것은 함정이다. 만약 당신이 그것을 완전히 피한다면, 당신의 생활은 더욱 간단하고 쉬워질 것이다.
왜 이러는지, 무슨 문제가 생길지, 그리고 네가 해야 할 일을 이야기해 보자.

아폴로의 문제

In practice, "industry-standard GraphQL implementation" means 169 separate npm packages Getting Started guide:
  • 44개의 다른 서버 패키지와 apollo-server-* 하위 패키지가 있습니다.
  • 7개의 서로 다른 GraphQL'전송층'과 이를 바탕으로 구축된 긴 체인 층의 확장.
  • 8 코드 생성 팩
  • 5가지 다른 create-* 프로젝트 설정 패키지
  • 3개의 서로 다른 GraphQL Babel 플러그인(Relay un Babel 플러그인 1개를 추가하여 특정 상황에서 Babel 사용을 피할 수 있음)
  • 더 많이...
  • reporting engine에서 권장하는 기본 apollo-server 패키지를 설치하는 데 필요한 아폴로 패키지에는'아폴로 스튜디오'(née Apollo Graph Manager, née Apollo Engine) extra protobuf definitions이 포함되어 있으며, 서버와 그들의 클라우드 서비스를 통합한 다음에 request tracing을 추가하여 Protobuf로 클라우드 서비스에 보고합니다.여기에는 사용자 지정 추적 형식에 대한 multiple, 사용자 지정 캐시 팩에 대한 different, 많은 전송 링크 계층에 전원을 공급하는 abstraction layer, 외부 데이터 소스에 대한 abstraction layer이 포함됩니다.
    전체적으로 apollo-server을 설치하면 실제로 33개의 직접 의존 항목이 설치되고 총 179개의 소프트웨어 패키지가 설치되며 약 35MB의 자바스크립트를 사용했다.
    일단 모두 통합되면, 이 가방 자체는 아무것도 할 수 없는 웹 서버를 만들 것이다.
    그러나 만약에 (공식, 비아폴로의) graphql 소프트웨어 패키지를 사용한다면 당신은 현재 다음과 같은 복잡한 문제를 대체적으로 대답할 수 있습니다.
    {
      books {
        title
        author
      }
    }
    
    명확한 것은 graphql 패키지는 공식적인GraphQL JS로 하나의 모델, 하나의 조회와 하나의 해석기(실제로는 하나의 데이터 집합 대상)를 받아들이고 결과를 제시해야 한다.HTTP를 제외하고는 유사한 조회를 처리하는 데 필요한 모든 GraphQL의 번거로운 작업을 완성한 것이다.
    나는 내가 이곳에서 아폴로에게 매우 엄격하다는 것을 안다. 이것은 완전히 공평하지 않다.그들이 발표한 대부분의 소프트웨어 패키지는 정말 유용한 상황이 있다. 내가 통계한 많은 소프트웨어 패키지는 모두 추천하지 않거나 중복된 것이다(이미 발표되었지만 자주 사용한다). 내가 아는 바에 의하면 그들이 발표한 모든 소프트웨어 패키지는 매우 효과적이다.나는 당연히 누구도 아폴로를 사용해야 한다고 생각하지 않는다!
    나는 아폴로가 누구의 GraphQL의 출발점이 되어서는 안 된다고 확신한다. 그럼에도 불구하고, 그것은 여전히 이렇게 마케팅되고 있다.
    그들은 분명히 생태계의 입구가 되고 싶어 한다. 그들은 당연히 생각하고 있다.신흥 급속한 성장 생태계를 당신의 무료 도구에 의존하도록 확보하는 것은 좋은 창업 전략이다.이것들은'graphql 서버를 어떻게 설정하는가'의 첫 번째 결과이다. 이것들은graphql 요가(Apollo 서버의 또 다른 소프트웨어 패키지)든 모두 이 페이지의 대다수 다른 글(Digital Ocean's docs부터 howtographql.com)에서 제안한 초보자 옵션이다.이것은 건강하지 않다.
    GraphQL API를 설정하려면 이 모든 것이 필요하지 않습니다.스왑 가능한 전송 계층과 데이터 소스, 요청 추적, 멋진 GraphQL 확장(예: @defer) 및 다중 캐시 정책은 모두 그 위치를 차지하지만, 단순한 API를'프로덕션'할 필요가 없는 복잡성에서 시작하고 싶지 않습니다.
    Apollo가 이러한 기능을 제공하는 것은 좋지만, 이 기능들은 Apollo를 사용하기 시작하지 않았더라도 나중에 추가할 수 있습니다.GraphQL 모드는 상당히 표준적이며 표준 도구에서 Apollo로 이식할 수 있습니다. (그러나 Apollo 자체의 확장을 사용하기 시작하면 반드시 되돌아갈 수 없습니다.)
    만약 내가 개인적으로 이것에 대해 화를 낸다면, 그것은 내가 화가 났기 때문이다!나도 여기 타 죽었어.
    HTTP Toolkit의 내부 API(예: for defining HTTP mocking rules and querying traffic)는 항상 GraphQL을 사용합니다.이 API들은 처음에 Apollo를 바탕으로 개발되었는데, 이것은 광범위하게 추천되고 기록되는 옵션이기 때문이다.이렇게 하는 데 필요한 너무 복잡한 설정은 일련의 심각한 통증을 초래한다.
  • 아폴로의 패키지는 사물을 신속하게 이동하고 깨뜨리는 것을 좋아하고 모든 패키지는 특정한 충돌 graphql의 대등한 의존항을 필요로 하기 때문에 모든 패키지가 현저한 업데이트 painful을 실시했다.
  • 기본 패키지는 많은 기능과 하위 의존 항목을 포함하는데 위에서 말한 바와 같이 이것은 대량의 빈틈 보고서를 의미한다.비록 빈틈이 관련되지 않거나 이용할 수 없다 하더라도 내 소프트웨어 패키지의 하위 사용자들은 don't want security warnings을 매우 합리적으로 사용할 것이다. 이것은 모든 내용을 반드시 최신식으로 유지해야 한다.
  • 일부 Apollo 패키지는 사실상 유지보수가 되지 않습니다. 이는 서로 충돌하는 의존 관계가 전체 패키지를 완성하지 않으면 업그레이드를 막을 수 있다는 것을 의미합니다.
  • 시스템에서 Apollo의 상호작용 패키지를 여러 개 사용하기 시작하면 상황은 더욱 나빠질 것이다. 왜냐하면 의존 패키지는lockstep에서 업데이트가 필요하거나 대등한 의존 상호작용이 폭발하여 조각이 수 마일 흩어져 있기 때문이다.
  • 에 관련된 소프트웨어 패키지는 매우 방대하다. 당신이 어떤 일을 시작하기 전에 apollo-server에만 35MB의 JS를 설치했다. (이것은 v2이다. 그 크기는 이전 Apollo Server v1 버전의 2.3배이다. 그러나 헤헤, 아무리 업그레이드를 해도 피할 수 없다. 그럼 누가 계산하겠는가?)
  • 이러한 문제가 갈수록 심각해지고 있습니다. apollo-server v3은 GraphQL 연합, 비노드 백엔드 플랫폼에 대한 지원과 새로운 플러그인 API를 내장하여 출시될 예정이다.오해하지 마세요. 이 기능들은 매우 멋있지만, 초보자 프로젝트에 기본적으로 포함할 필요는 없습니다.
  • 이거 재미없어.그러나 다음 중 하나를 선택할 수 있습니다.

    간단한 GraphQL 서버를 구축하는 방법 (Apollo 없음)

    To build a GraphQL API server, you really need just 3 things:

    1. A web server
    2. An executable GraphQL schema (i.e. a schema and a resolver) which can together can answer GraphQL queries
    3. A request handler that can accept GraphQL requests, hand them to the schema, and return the results or errors
    I'm assuming you already have a preferred web server (if not, Express은 간단하고 편리하며 신뢰할 수 있는 선택입니다).공식 graphql 패키지는 문자열 모드와 해상도 대상을 실행 가능한 모드로 변환할 수 있습니다.
    나머지 마지막 단계는 express-graphql 으로 처리하기 쉽다. 간단한 Express 중간부품으로 4개의 처리 내용 협상과 본문 해석의 의존항만 있다.이것은 Express 또는 Connect에 적합하며 다른 대부분의 서버에서도 이와 유사한 작은 패키지가 있습니다.
    GraphQL 서버를 설정하려면 다음 패키지를 설치합니다.
    npm install express graphql express-graphql
    
    그런 다음 해당 서버를 사용하도록 설정합니다.
    const express = require('express');
    const { graphqlHTTP } = require('express-graphql');
    const { buildSchema } = require('graphql');
    
    // Create a server:
    const app = express();
    
    // Create a schema and a root resolver:
    const schema = buildSchema(`
        type Book {
            title: String!
            author: String!
        }
    
        type Query {
            books: [Book]
        }
    `);
    
    const rootValue = {
        books: [
            {
                title: "The Name of the Wind",
                author: "Patrick Rothfuss",
            },
            {
                title: "The Wise Man's Fear",
                author: "Patrick Rothfuss",
            }
        ]
    };
    
    // Use those to handle incoming requests:
    app.use(graphqlHTTP({
        schema,
        rootValue
    }));
    
    // Start the server:
    app.listen(8080, () => console.log("Server started on port 8080"));
    
    뛰어라, 너는 끝장이야.이것은 대부분의 초기 용례에 있어서 믿을 만하고 빠르며 충분하다.그것도 매우 짧고 뚜렷하며 상대적으로 작다. 이곳의 node_modules은 아폴로호의 15% 이상에 해당한다.80퍼센트의 코드를 운행하는 것은 매우 좋은 일이다.
    또한 당신이 필요로 하는 부분에만 복잡성과 기능을 추가할 수 있는 추가 기능을 추가할 수 있다.
    예를 들어, 나의 예에서, 나는 구독하고 싶다.Mockttp(HTTP Toolkit 에이전트의 내부)은 웹소켓을 통해GraphQL 조회를 받기 때문에 클라이언트가 들어갈 때 캡처된 요청의 세부 사항을 클라이언트에게 전송할 수 있다. a GraphQL schema은 다음과 같다.
    type Subscription {
        requestInitiated: InitiatedRequest!
        requestReceived: Request!
        responseCompleted: Response!
        requestAborted: Request!
        failedTlsRequest: TlsRequest!
        failedClientRequest: ClientError!
    }
    
    이 점을 추가하려면 위의 기본 설정을 펼칠 수 있습니다.이를 위해 나는 실제로 몇 개의 작은 아폴로 모듈을 사용했다!대다수는 독립적으로 선택하고 배치할 수 있다.이러한 상황에 대해 graphql-subscriptions 은 해석기에서 작업하는pubsub 논리를 제공했고 subscriptions-transport-ws 은 이를 Express에 집적하여 웹소켓을 자체적으로 처리했다.매우 유용하다
    다음은 완전한 예입니다.
    const express = require('express');
    const { graphqlHTTP } = require('express-graphql');
    const { buildSchema, execute, subscribe } = require('graphql');
    
    // Pull in some specific Apollo packages:
    const { PubSub } = require('graphql-subscriptions');
    const { SubscriptionServer } = require('subscriptions-transport-ws');
    
    // Create a server:
    const app = express();
    
    // Create a schema and a root resolver:
    const schema = buildSchema(`
        type Book {
            title: String!
            author: String!
        }
    
        type Query {
            books: [Book]
        }
    
        type Subscription { # New: subscribe to all the latest books!
            newBooks: Book!
        }
    `);
    
    const pubsub = new PubSub();
    const rootValue = {
        books: [
            {
                title: "The Name of the Wind",
                author: "Patrick Rothfuss",
            },
            {
                title: "The Wise Man's Fear",
                author: "Patrick Rothfuss",
            }
        ],
        newBooks: () => pubsub.asyncIterator("BOOKS_TOPIC")
    };
    
    // Handle incoming HTTP requests as before:
    app.use(graphqlHTTP({
        schema,
        rootValue
    }));
    
    // Start the server:
    const server = app.listen(8080, () => console.log("Server started on port 8080"));
    
    // Handle incoming websocket subscriptions too:
    SubscriptionServer.create({ schema, rootValue, execute, subscribe }, {
        server // Listens for 'upgrade' websocket events on the raw server
    });
    
    // ...some time later, push updates to subscribers:
    pubsub.publish("BOOKS_TOPIC", {
        title: 'The Doors of Stone',
        author: 'Patrick Rothfuss',
    });
    
    나의 관점은 당신의 프로그램이 구독을 필요로 하거나, 모든 사람이 이 추가 패키지를 사용해야 한다는 것이 아니다. (정반대이다.)
    그러나 이것은 이러한 기능을 점차적으로 사용하기 위해 설정을 확장하는 방법을 확실히 보여 준다.요청/응답 모델에서 구독 지원으로 전환하는 것은 보잘것없는 변화가 아니지만 이런 상황에서도 Apollo 확장을 추가하는 것은 기존 논리 위에 있는 몇 줄의 간단한 코드로 표준 설정에 적합하다.
    Apollo 도구가 아닌 도구를 사용하여 확장할 수도 있습니다.여기서 우리는 주로 바닐라 GraphQL 패키지와 Express를 둘러싸고 Apollo 구성 요소를 그것들에 기초하지 않고 단독으로 조합한다.이것은 사용자가 좋아하는 다른 Express 중간부품이나GraphQL 도구를 사용할 수 있음을 의미합니다. 인증, 캐시, 로그 기록 또는 다른 횡단 기능을 추가할 수 있습니다. 표준적인 비GraphQL 솔루션과 예시만 사용하면 Apollo 생태계의 잠금이 필요하지 않습니다.
    아폴로는 생태계를 위한 노력과 공헌을 칭찬받아야 할 재미있고 유용한 소프트웨어 패키지가 많다.하지만 중립적인 배우도 아니다.다음 큰일이 당신의 프로젝트에 대한 정확한 선택이라고 생각하지 마라. 특히 그것이 '업계 표준' 이라고 자칭한다면.
    반대로 간단함부터 시작하라. 불필요한 복잡성을 피하고 프로젝트를 간소화하고 유연하게 유지할 수 있는 시스템을 구축해라.
    GraphQL을 사용하여 실시간 데이터를 디버깅, 재작성, 시뮬레이션하시겠습니까?Try out HTTP Toolkit . 브라우저, 서버, 안드로이드 등에 대한 원클릭 HTTP 차단 및 디버깅

    좋은 웹페이지 즐겨찾기