标签：ring out multiple ali cab designed ble local addition
转自：https://blog.apollographql.com/apollo-federation-f260cf525d21
What if you could access all of your organization’s data by typing a single GraphQL query, even if that data lived in separate places? Up until now, this goal has been difficult to achieve without committing to a monolithic architecture or writing fragile schema stitching code.
Ideally, we want to expose one graph for all of our organization’s data without experiencing the pitfalls of a monolith. What if we could have the best of both worlds: a complete schema to connect all of our data with a distributed architecture so teams can own their portion of the graph?
That dream is finally a reality with the launch of Apollo Federation, an architecture for building a distributed graph. Best of all, it’s open source! ?? Try it out now or keep reading to learn more.
Apollo Federation is our answer for implementing GraphQL in a microservice architecture. It’s designed to replace schema stitching and solve pain points such as coordination, separation of concerns, and brittle gateway code.
Federation is based on these core principles:
Apollo Federation is inspired by years of conversations with teams that use GraphQL to power their most important projects. Time and time again, we’ve heard from developers that they need an efficient way to connect data across services. Let’s learn how in the next section!
Connecting data between multiple services is where federation truly shines. The two essential techniques for connecting data are type references and type extensions. A type that can be connected to a different service in the graph is called an entity, and we specify directives on it to indicate how both services should connect.
With Apollo Federation, we can declaratively reference types that live in different schemas. Let’s look at an example where we have two separate services for accounts and reviews. We want to create a User type that is referenced by both services.
In the accounts service, we use the @key directive to convert the User type to an entity. With only one line of code, we’ve indicated that the User type can be connected from other services in the graph through its id field.
In the reviews service, we can return the User type even though it’s defined in a different service. Thanks to type references, we can seamlessly connect the accounts and reviews service in one complete graph.
type Review {
author: User
}
On the client, you can query the data as if both types were defined in the same schema. You no longer have to create extra field names like authorId or make separate round trips to a different service.
query GetReviews {
reviews {
author {
username
}
}
}
To enable organizing services by concern, a service can extend a type defined in a different service to add new fields.
In the reviews service, we extend the User entity from the accounts service. First, we use the @key directive to specify that these two services should connect together on the id field defined in the @external accounts service. Then, we add the functionality for a user to fetch their reviews.
extend type User @key(fields: "id") {
id: ID! @external
reviews: [Review]
}
The client only sees the final User type, which includes all of the fields merged together. Type extensions for Apollo Federation will feel familiar if you’ve used Apollo Client for local state management because they share the same programming model.
We designed Apollo Federation to be approachable to start with, yet capable of handling the most complex real-world use cases:
@key directives.@provides directive, services can use that denormalization to their advantage to provide shortcuts for fetching data faster.
To implement Apollo Federation, you need two components:
@key directive.Setting up federation with Apollo Server doesn’t require any manual stitching code. Once you have your services, you can spin up a gateway simply by passing them as a list:
const { ApolloGateway } = require("@apollo/gateway");
const gateway = new ApolloGateway({
serviceList: [
{ name: "accounts", url: "https://pw678w138q.sse.codesandbox.io/graphql" },
{ name: "reviews", url: "https://0yo165yq9v.sse.codesandbox.io/graphql" },
{ name: "products", url: "https://x7jn4y20pp.sse.codesandbox.io/graphql" },
{ name: "inventory", url: "https://o5oxqmn7j9.sse.codesandbox.io/graphql" }
]
});
The gateway crunches all of this into a single schema, indistinguishable from a hand-written monolith. To any client consuming a federated graph, it’s just regular GraphQL.
We didn’t want the gateway to be a black box where federated schemas and queries magically turn into data. To give teams full visibility into what’s happening with their composed graph, Apollo Server provides a query plan inspector out of the box:
We’re excited to open source Apollo Federation and get feedback from the community. To get started, we’ve created an example repo that demonstrates how to build a federated graph with four services and a gateway. If you want to play with the example in the browser, check out this CodeSandbox.
Along with the example app, we added a new section to the Apollo Server docs about federation. Read the docs to get up to speed quickly and migrate over from schema stitching.
This release is the first chapter of distributed GraphQL. We can’t wait to hear about the many exciting ideas that stem from federation and see the amazing things you build. In the future, we’re eager to work with the GraphQL community to support new features and tools such as:
@deferWe’d love to hear your feedback on Apollo Federation. Join the conversation on Spectrum and let us know what you think!
A revolutionary architecture for building a distributed graph
标签：ring out multiple ali cab designed ble local addition
原文地址：https://www.cnblogs.com/rongfengliang/p/10984264.html
