DEV Community: Ayush Vishwakarma

Crafting the Ultimate GraphQL Adventure with Express: Power Up Your API Game!

Ayush Vishwakarma — Sun, 11 Aug 2024 15:59:39 +0000

Hey everyone! As a frontend developer, I've been diving into some backend technologies lately—because let's face it, knowing your way around the backend can save you from any sneaky surprises from your backend developers! 😛

After getting a good grasp of the basics in the MERN stack, I stumbled upon GraphQL, and I have to say, I'm pretty blown away by its potential. It's a game-changer, and I thought it would be fun to share my insights with you all. Let's explore the magic of GraphQL with express together!

Introduction

For people who are fairly new to GraphQL, let me give you a fair introduction to this powerful tool.

GraphQL, as the official website puts it, is A query language for your API. If you've been in the industry for a while, you've likely encountered situations where an API response gives you way more data than you actually need. With a traditional REST API, whether you're using all the keys or just a couple, the entire payload is sent to the client—like getting the entire buffet when all you wanted was a snack.😶‍🌫️

This can lead to inefficiencies, especially when you're only interested in specific data points for different parts of your application. GraphQL tackles this challenge head-on, allowing you to request only what you need, no more, no less. It's like having a tailor-made suit instead of one-size-fits-all!

Let's Get Our Hands Dirty

We’ll tackle this in two main steps:

Creating a GraphQL Server with Apollo Client
Connecting GraphQL with Express

By the end, you'll not only have a GraphQL server up and running, but you'll also know how to connect it with Express. So, roll up your sleeves—it's time to turn code into magic!

Creating a GraphQL Server with Apollo Client

Let's get started by setting up our GraphQL server. First, we'll lay the groundwork with some essential tools.

Initialize an Empty npm Folder

Begin by initializing an npm project. This sets up your project directory with a package.json file that will track your dependencies:

npm init -y

This command will create a basic package.json file with all the default settings—kind of like getting the keys to your new coding kingdom.

Install Express, Apollo Server, Dotenv and GraphQL

Next, we'll bring in the core tools: express for our server, Apollo for our GraphQL needs, and GraphQL itself:

npm i express @apollo/server graphql dotenv

With this, you're setting up the foundation of your GraphQL server. Think of it as assembling the ingredients for a gourmet meal—each one is essential for the final dish.

Install nodemon for Hassle-Free Development

To make your development process smoother, we’ll add nodemon as dev dependencies, nodemon will watch your files for changes and automatically restart the server.

npm i -D nodemon

nodemon is like having a trusty sidekick who handles the grunt work, so you can focus on coding.

Create a src Folder and server.js File

Now, let’s set up the structure of our project. Start by creating a src folder, where all your source code will live. Then, create a server.js file inside src—this will be the starting point of our application:

After installing all these dependencies, your package.json file should look something like this:

With this setup, you're now ready to start building your GraphQL server. Buckle up—this is where the real adventure begins!

In our server.js file we'll need to import bunch of things as shown below

Let’s walk through the key lines in our server.js file:

Apollo and Server Setup: We import ApolloServer and startStandaloneServer to get our GraphQL server rolling, while dotenv handles our environment variables like a pro.
We initialize an ApolloServer instance, primarily requiring typeDefs to define the schema. In the provided example, we specify a Query type named check, which is of type String and marked as non-nullable, ensuring that the query will always return a valid string.
In addition to typeDefs, the resolvers argument is mandatory. It specifies how to handle and resolve the requested queries. In this case, we’ve defined a resolver for the check query that logs the message checking query and returns a non-nullable string Checking Query, consistent with the schema defined in typeDefs.
Finally, we start the server. If all goes well, you’ll see a message in the console confirming that your server is up and running!

Now when you start the server, you'll be able to see a screen similar to the one shown below

Connecting GraphQL with Express

Now that we’ve got our Apollo Server for GraphQL up and running, let’s integrate it with a REST API using Express. It’s a simple tweak, and you’ll be up and running in no time. Follow these steps to make the switch:

First, we need to bring in express from express and the expressMiddleware from Apollo Server. This will allow us to blend the best of both REST and GraphQL worlds.
Next, we’ll create an instance of an Express app. This will serve as the backbone for our server, handling both REST routes and our GraphQL endpoint.
We’ll call the start method from the ApolloServer instance. This prepares the server to handle incoming requests when connected to Express.
Finally, we’ll create a /graphql endpoint where our Apollo Server will handle requests using expressMiddleware. This is where the magic happens—combining the flexibility of GraphQL with the simplicity of Express.

Here’s what your updated server.js will look like after making these changes:

And just like that, when you navigate to http://localhost:8002/graphql, you’ll be greeted by the familiar Apollo Server interface, ready to handle your queries.

Congratulations! You’ve successfully set up a GraphQL server and integrated it with Express. It’s a powerful combo that’s now at your fingertips.

Feel free to share your thoughts in the comments—I’d love to hear how this worked for you. I hope you found this guide helpful, and maybe even a little fun!

Caching the React Query Way!

Ayush Vishwakarma — Sat, 19 Nov 2022 18:44:57 +0000

Recently I had a chance to learn react-query, and after having used Angular and HttPClient for API calls for over an year I found this really amazing and easy to use as it provides bunch of different configurable parameters which solves a massive chunk of common problems for which we had to write functions manually.

A major problem that we all must have faced is CACHING! Traditionally, if we had to cache any data and prevent an API from being called again and again, we needed to store that data somewhere (in BehaviourSubject or localstorage, if you work with Angular) and every-time before calling an API we had to check if the data is already stored anywhere, if yes we could just use that or else go ahead and fetch data using API. A small code snippet for the same use case is provided

The above is an example of AppComponent of angular where we are fetching the Super Heros data using getSuperHeros function. This function first checks if the data is already stored in a BehaviourSubject, and if it does it simply assigns the data to the superHeros variable else it goes ahead and makes an API call to fetch the data and store it in the BehaviourSubject.

Although there is no issue with the above implementation, one major question that arises is, "for how long the data will be cached?".

There are different answers for it based on what you use for storing the data.

If you've used BehaviourSubject or anything similar to it that persists till the page is reloaded, the data will be cached till page is reloaded.

If you've used localstorage that persists even if the page is reloaded, your data will be cached till the time you clear your localStorage. If you want your App to periodically look for changes, you'll have to store an interval along with the cached data and make API calls to see if the data from server has changed.

Looks a very tedious job... right?

You can achieve the above functionality with just two properties in react-query.

cacheTime
staleTime

Before we dive into above properties a little bit about useQuery a very important hook from react-query

useQuery

The above image is an basic example of how we fetch data in React using useQuery hook from react-query.

useQuery accepts multiple arguments first of which is queryKey an unique key (which in our case is very important), second is queryFn a function that is called to actually hit the endpoint, third is an object which contains multiple configurational options such as refetchOnWindowFocus, cacheTime, staleTime, etc...

It also returns an object which when expanded contains multiple fields of which data, isLoading, isFetching, being the important ones in context to this article

- data

data is the same object that is returned from API, it is provided to us by useQuery

- isLoading

isLoading is a boolean. It is set to true when the data fetched from the API is being loaded and set to false when the data is loaded completely

- isFetching

isFetching is a boolean. It is set to true when the API call starts and set to false when the API call ends

Now let's have a look on the two properties that is used to achieve caching

cacheTime

cacheTime property accepts time(in ms) which determines how long the data from the API will be cached. By default it is set to 5 mins.

In the above example, when we land on the App for the first time the following steps takes place in order to show the data

useQuery hooks triggers superHeroFetcher function
isFetching is set to true
isLoading is set to true
API call takes place
data is populated
isFetching is set to false
isLoading is set to false

and then we're able to see the data fetched from API on screen.

But if we visit the App for the second time the following steps takes place

useQuery hooks triggers superHeroFetcher function
isFetching is set to true
isLoading is set to false
API call takes place
data is populated
isFetching is set to false
isLoading is set to false

See the difference?

Since the data is cached, using the unique key (queryKey). isLoading property is never set to true and we won't see a Loading screen. However, an API call is still made and isFetching is set to true and then to false and if there is any change in data the updated data object is returned.

To prevent this extra API call, staleTime is the property that is to be used

staleTime

staleTime property accepts time(in ms) too and it determines for how long the data that is cached will be stale. By default it is set to 0 which means everytime you visit a page the API call will be triggered.

In the above image both staleTime and cacheTime are set to 3 mins each.

Cheers!🥂