If you have not already read the first part and second part of the blog on Building a Serverless GraphQL API with Prisma, Apollo & TypeGraphQL-Prisma, I recommend doing so before proceeding with this third part.
Actually, we still have a few steps left before we can deploy our Lambda function. In this part, we will focus on configuring Apollo Server and building our GraphQL schema. We will also see how we can integrate Prisma into our resolvers and mutations using TypeGraphQL.
Here are the steps we will cover in this part:
1. Set up Apollo Server with the necessary configurations and plugins.
2. Define our GraphQL schema using TypeGraphQL decorators.
3. Implement resolvers and mutations that use Prisma to query and manipulate data from the PostgreSQL database.
4. Test our GraphQL API.
First, install the @apollo/server and @as-integrations/aws-lambda packages using the following command:
npm install @apollo/server @as-integrations/aws-lambda
also Reflect Metadata library to add metadata to a class, method, property, or parameter at runtime and then retrieve that metadata later.
npm i reflect-metadata
@apollo/server is a popular package for building GraphQL APIs. It provides a flexible and powerful framework for defining your schema, implementing your resolvers, and handling queries and mutations.
@as-integrations/aws-lambda is a package that allows you to deploy your Apollo Server instance to AWS Lambda. This package handles the details of setting up the Lambda function and integrating it with API Gateway, so you can focus on building your GraphQL API without worrying about the infrastructure.
Rearrange your folder hierarchy in the following manner.
· Libs/db-connection.ts-where, we define a reusable Prisma Client
· Manage-user/handler.ts :- where we create our apollo server and define our Lambda handler.
· User.resolver,ts :- where we create our resolvers.
· User.InputType.model.ts :- where we create define an input type for a User object in a GraphQL schema.
· User.repository.ts:-where we handle persistence operations related to a User entity in a database or other data source.
· User.service.ts:-where we handle business logic and acts as an intermediary between the GraphQL API and the data access layer
We can instantiate a new Prisma Client that’s reusable in db-connection.ts
Repository is used in this serverless application to define a repository that handles persistence operations related to a User entity in a database or other data source. Let’s define this in user.repository.ts
Service layer used in this serverless application to define a service that handles business logic and acts as an intermediary between the GraphQL API and the repository. Let’s define this in user.service.ts
Resolvers are a key part of GraphQL because they allow developers to manipulate data from multiple sources and combine it into a single response, and they give developers fine-grained control over the shape of the data returned to the client.
In above schema we have defined, · GraphQL queries :- A query is an operation that retrieves data from the GraphQL server. Queries are read-only operations, meaning they cannot
modify any data on the server.here I use it to retrieve all user records from a data source. · GraphQL mutations :- A mutation is an operation that modifies data on the GraphQL server. Mutations are represented in the GraphQL schema using the mutation type. Here I use it to create a new user
The schema is built synchronously and takes an object with property ManageUserResolver we built earlier.
Then create a new Apollo Server instance using the ApolloServer constructor from the @apollo/server library. The schema object created in the previous step is passed as an argument to the constructor.
The createALBEventRequestHandler function is also passed as an argument to startServerAndCreateLambdaHandler, which is used to create a handler for Application Load Balancer (ALB) events.
Now ,We are going to wrap our handler in manage-user/index.ts as shown below so that we can simply send it to the functions property in serverless.ts.
once the lamda function is defined in the code, it can be exported from the module and used as the handler function for the corresponding AWS Lambda function in the serverless.ts file.
By running serverless offline, you can start a local server that listens for requests on the same endpoints as your deployed AWS Lambda functions. This can be useful for testing and debugging your serverless application locally before deploying it to AWS.
serverles offline
Then you can head to http://localhost:3000/dev/manage-user to explore the graph we’ve built. https://youtu.be/MI8eTN4TqZ0
The complete code is available on this link. Github link :- Nuwa-Hub/serverless-api-blog (github.com)
