Apollo Server provides an easy way for new, or existing, applications to get running quickly. Existing applications can take advantage of middleware and new applications can utilize an integrated web-server. Both of these servers can be configured with minimal configuration and follow industry best-practices.
> If you don't understand these prerequisites, we recommend starting at the [Getting Started](../getting-started.html) page for a simplified example. Alternatively, visit the links to the right of the prerequisites above for more information.
* [`graphql`](//npm.im/graphql): A support library, provided by Facebook. It won't be explicitly used in these examples, but is a required module and shared amongst all GraphQL libraries in the project.
Depending on whether we are creating a new application or an existing application, the method of importing `apollo-server` will vary slightly since Apollo Server must adapt to the semantics of existing servers (e.g. Express, Hapi, etc.)
Both import methods will use the `apollo-server` module we installed in the previous step and import an `ApolloServer` class. But existing applications will specify the desired middleware as a path-specific import (e.g. `apollo-server/<variant>`).
For new applications, it's not necessary to use a middleware variant and Apollo Server comes ready to run. In this case, we'll **add this line** to the top of an application's main entry-point then skip ahead to "Import type definitions" below:
Existing applications generally already have existing middleware in place and Apollo Server works with those existing middleware options. But in order to play along, we need to import the `ApolloServer which corresponds to the type of server which is already in use.
For example, if the application is already using an Express server, it is important to use the `apollo-server/express` import.
It will also be necessary to have access to the existing "app" in order to add the additional Apollo Server middleware. In many applications (especially Express) this is usually called `app`.
Apollo Server works great in so-called "serverless" environments such as Amazon Lambda and Microsoft Azure Functions. These implementations have some extra considerations which won't be covered in this guide, but more information is provided in [Server-less]().
Before we can use the `ApolloServer` we've imported above, we'll need create an empty starting point for type definitions. We'll also create an empty "resolver map", but we won't discuss it further until the next page of this guide.
Add the following code to the same file you added the `apollo-server` import above:
At this point, we're ready to start accepting connections to the server. This is done by calling the `listen` method on the instance of `ApolloServer` which was created in the previous step:
> By default, Apollo Server listens on port 4000. See the [API reference](../api/apollo-server.html) for additional `listen` options, including how to configure the port.
With the above configuration complete, we can now start the Node application, with Apollo Server, for the first time. This varies, but assuming a standard `index.js` configuration, might be as simple as `node index.js`.
After you start the server it should print a message to the console indicating that it's ready:
```shell
$ node index.js
🚀 Server ready at http://localhost:4000/graphiql
```
At this point, if the message isn't printed to the console, it's possible that something went wrong. Double-check the previous steps in this guide, and try comparing the configuration to our [pre-configured example on Glitch]().
## Explore
To explore the newly created GraphQL server, open a browser to the link shown in the console, http://localhost:4000/graphiql.
Now that the GraphQL server is running, it's time to start exploring how we'll fetch data for our types. We'll get started on that in the [next step](./data.html).