간단한 방법으로 그림을 만들거나: 아폴로를 사용하지 마라
이 중 약 90퍼센트는 Apollo이라는 투기회사가 건설하고 대대적으로 보급한 것이다.아폴로는 자신을'데이터 그래픽 플랫폼'으로 묘사하고 자신이 묘사한'업계 표준GraphQL 실현'을 구축했다.
불행하게도, 나는 그들의 플랫폼이 매우 좋다고 확신하지만, 만약 당신이 새로운GraphQL API를 세우고 있다면, 당신은 Apollo로부터 시작해서는 안 된다.이것은 나중에 틀림없이 쓸모가 있을 것이다. 그러나 첫날, 이것은 함정이다. 만약 당신이 그것을 완전히 피한다면, 당신의 생활은 더욱 간단하고 쉬워질 것이다.
왜 이러는지, 무슨 문제가 생길지, 그리고 네가 해야 할 일을 이야기해 보자.
아폴로의 문제
In practice, "industry-standard GraphQL implementation" means 169 separate npm packages Getting Started guide:apollo-server-*
하위 패키지가 있습니다.create-*
프로젝트 설정 패키지 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을 실시했다.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:
- A web server
- An executable GraphQL schema (i.e. a schema and a resolver) which can together can answer GraphQL queries
- A request handler that can accept GraphQL requests, hand them to the schema, and return the results or errors
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 차단 및 디버깅
Reference
이 문제에 관하여(간단한 방법으로 그림을 만들거나: 아폴로를 사용하지 마라), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/pimterry/graphql-the-simple-way-or-don-t-use-apollo-8l3텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)