Using Apollo Server as our server

We are going to create a new server implementation for this project, rather than reusing any of the server infrastructure from the previous chapter. Apollo provides its own server implementation (called Apollo Server), which we are going to use in place of Express. As usual, we are going to start off by bringing in the necessary types, and then we will create our class with the class definition. In the constructor, we are going to bring in a reference to our Mongo database class.

Apollo Server is part of the overall Apollo GraphQL strategy for providing out-of-the-box GraphQL support. The server can either stand on its own or work with server frameworks such as Express for serving up self-documenting GraphQL data. The reason we are going to use Apollo Server is because it has built-in support for working with GraphQL schemas. If we were to try and add this support ourselves, we would end up redoing what we get for free from Apollo Server.

First, we are going to import our types:

npm install apollo-server apollo-server-express --save

Then, we are going to write our server class:

export class MyApp {
constructor(private mongo: Mongo = new Mongo()) { }
}

Our server is going to expose a Start method that will be responsible for connecting to the database and starting our Apollo Server:

public async Start(): Promise<void> {
this.mongo.Connect();

await Prefill.Instance.Populate();

const server = new ApolloServer({ schema, playground: true });
await server.listen(3000);
}

When we create our Apollo Server instance, we indicate that we want to use GraphQLSchema, but we don't define anything about that schema. We use the buildSchema function, which takes a series of options and uses them to bring in the schema that Apollo Server will use. resolvers takes an array of GraphQL resolvers, so we are going to supply TodoItemResolver as the resolver we want to use. The implication here, of course, is that we can use multiple resolvers.

The validate flag states whether or not we want to validate objects that are passed into resolver parameters. Since we are using simple objects and types, we are going to set this to false.

Something I like to do to validate the GQL I am creating is to emit the schema using emitSchemaFile. This uses the path operation to build up a fully qualified path name. In this case, we will be resolving to the dist folder, where we will output the apolloschema.gql file:

const schema: GraphQLSchema = await buildSchema({
resolvers: [TodoItemResolver],
validate: false,
emitSchemaFile: path.resolve(__dirname, 'apolloschema.gql')
});

Now that we have finished coding the server side up, we can add new MyApp().Start(); to start and run our application. When we build and run our server side, it will start an instance of our Apollo-enabled GraphQL server on http://localhost:3000. We do have one little surprise left and it's to do with the last parameter that we supply to the Apollo Server options, namely playground: true. The playground is a visual editor area that lets us run graphql queries and see what results they bring.

I would recommend switching the playground off in production code. For testing purposes, however, it is an invaluable aid for trying out queries.

In order to check that we have everything wired up correctly, try entering a GraphQL query into the query window. While entering the query, remember that just because there is a superficial resemblance to a JavaScript object, there is no need to use separate entries. Here's a sample query to get started with. This query exercises the TodoItems query we created in TodoItemResolver:

query {
TodoItems {
Id
Title
Description
Completed
DaysCreated
}
}
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.134.118.95