Talks Tech #48: Journey Into FullStack Apps With GraphQL + React

Talks Tech #48: Journey Into FullStack Apps With GraphQL + React

Written by WWC Team


GraphQL and React

iTunesSpotifyGoogleYouTubeMore Episodes

Nancy Crandall, Digital Dev Engineer III at CVS Health, shares her talk, “Journey Into FullStack Apps With GraphQL + React.” She compares React and GraphQL. She also shows how GraphQL is similar to JavaScript, so while it may be a newer language, it isn’t too unfamiliar.qqw

I’m more of a front-end developer. Within the last few years, I’ve been getting a little more into FullStack. When I started, I decided to start taking this approach by using Node.js and going a bit more into using JavaScript as a FullStack, doing the back-end and the front-end coding. GraphQL was created by Facebook in 2012, a query data language used to pull in APIs. It uses a single endpoint to create multiple versions of the same API. It’s also used mostly in a headless setup so that you would have a CMS.

They talked about using a CMS with WordPress and having a Headless setup. You could technically use GraphQL in that instance. React, and GraphQL have different approaches to things, especially the Schema Definition Language or the SDL. React is an endpoint tied to an identity resource, which means a lot of endpoints with different shapes. GraphQL has a custom schema that developers can use to describe multiple operations in the same link if they identify it with a different keyword. There’s also different handling of resources. React, if you want to make a call for the Women Who Code database that pulls the speakers and the topics, you would probably create multiple routes and have URL paths to create and pull in that information and data.GraphQL uses a single endpoint. You would do one call to your server or database and pull everything in. Both React and GraphQL have similar approaches to moving data and start functions. GraphQL repeats several times and requests details in the long run. This helps prevent over-fetching or under-fetching that often happens inside React API. 

React is better at handling caching and can use the get method. GraphQL uses mostly the post method to fetch data. URLs do not identify it, and it can cause some issues. There are a lot of resources and ways that you can fix it with GraphQL. React, and GraphQL were both created by Facebook. That means these two applications work incredibly well together. The GraphQL schema has a great, usable, understandable UI interface that you can review and make your queries. It’s also a little bit of an easier language. It looks like a very simple JSON array output. It’s not something that, as a front-end JavaScript developer, will be unfamiliar to you. The graphical structure will define the readable hierarchical structure and the relationships between those and everyday object type’s repeat components. It helps from object to type to object type to represent the component wrapping another component.

There are a lot of open sources, tutorials, and applications that you can use to help you extend it and make it easier to code in the backend. You’re not having to code everything, just vanilla JavaScript from scratch. It does not dictate a specific application structure, so your architecture and patterns can be introduced on the existing React API. You can also work with all their existing API management tools. You’re not structured into how to do stuff. There is a little bit of a learning curve, especially if you come from a React API setup and are used to doing that. There can be a lot of nested complexity. The nice thing is that you’re doing one post-call. The issue is if you have a lot of data that you’re pulling and you start nesting it. It can become complex and cause some issues. The biggest thing is that GraphQL shifts a lot of the work to the server side, so the server needs to do a lot more parsing, pairing, querying, and verifying parameters. The caching is a huge issue. With the React API, you can access multiple URLs. On the other hand, GraphQL is very complex because it needs to have each query identifying, and it operates as a different entity.

I’ve created a React on the front end and a node on the back-end project. I created a demo with the idea of having a CMS or if you have another pro website that you want to pull specific data from. In this use case, I want to pull all the speakers and their topics from the Women Who Code Database. I’m going to pull that into my remote React app then. I’m using all mock data. It will be a React application with Express and GraphQL and as a Node.js server. The database is just going to be using mock data JSON. In a future use case, I’d probably use MongoDB because it’s pretty, works well, and is also within many stacks. From a front-end perspective, this can be daunting. The good news is it’s all JavaScript. GraphQL is a new language, but it’s not too different. The nice thing is that Node.js is JavaScript, and the React app works beautifully with this.


This is basically what I would get from MongoDB. It is just a JSON array. I have some data topics and speakers that I’m pulling from the database, and this is basically what I would get in a JSON format. 

server data

How you would import any other package independently in a JavaScript project, you do the same thing with GraphQL. The nice thing about GraphQL is it’s very, very open-source. There are so many guidelines. They have lots of tutorials. There are around 18 ways to set up the projects, if not more. The GraphQL IDs and syntax are very similar to what we see as most JavaScript object types. It is like using JavaScript strings, integers, and numerates. The syntax will be very familiar that all front-end developers are used to and know how to do. This is all on the Express server side. We haven’t set up anything. This is just basically creating query types.

GraphQl query

On the left side, that’s the JSON data I’m pulling from the database. I’m making my query call from what I did in my Node Express. JavaScript is creating a little query, which is GraphQL, basically making a post command to grab the code and pull it into my GraphQL server. Then, it outputs it as that nice little JSON array. This is using the GraphQL Express library server or perhaps /GraphQL and the HTTP endpoint on port 4000, and that’s all I’m doing to have this all running.

GraphQL queries

Pulling in more data and creating a new query type, it’s just the same repeat, rinse and repeat. Creating another GraphQL object, you end up, especially on the node server side, just creating a lot of similar functions and pulling in different GraphQL objects and strings and what you want to pull out of your database. This is the powerhouse of GraphQL, using the single endpoint in the same database and being able to pull in the speakers like I do with the topics and just pulling in all that data.

more GraphQL Queries

Going through the same thing, creating a new query. You don’t have to specify if you’re doing a query. You can also have it as these two nice little brackets, and it will pull in my data. All I did was add in the speakers with it on top of my topics. Now I’m pulling all that data in. Now you’re getting both the topics and Women Who Code speakers. You don’t have to call in all the data. I have people’s occupations. Maybe I don’t want that, so it’s just removing it simply for my query, and then next, we’ll pull out and remove it for my data. This doesn’t dictate it on the React side. This is just the GraphQL UI that lets me know if I’m pulling in my queries correctly and also what kind of my endpoints could have basically output. I can see what I’m getting, and it’s nice. It will show you if you’re missing anything or have an error.


I’m a Vanilla JavaScript developer by trade. I used just the Vanilla JavaScript Fetch API to pull in my data like you would with any API. It will pull from our local host running the GraphQL express server in the background. I am now pulling in my query API data and then going through it, and you can see the same query that I dropped inside the GraphQL server’s UI. I’m now pulling that into my React project. This React project is a React Start app. I didn’t do anything with it. I didn’t have any other fancy stuff. I’m just dropping this straight into the app JS. I’m going to go ahead into useEffect and useStates because those are awesome tools that are used within React to make a network request.

React on Frontend

Since I’m also using the Vanilla JavaScript, the fetch API, I want to call out that the useEffect in a sense, is making an async call and a catch statement to pull on the data. Then, the useState is setting those speakers and set speakers to make it simple. I would compare it to a JavaScript of weight. After the data is set, it adds and passes those values into the useState array. Lower on the page, I would have my React Render here, and I want to validate that the data is being pulled in. I’m just using JSON stringify to output it onto the page using React, doing the best thing it can do. 

React with Query

Using those speakers to clean it up, doing one of the map arrays or map filters is one of the things that JavaScript React loves doing. Go through and loop that and then, later on, create also in the secondary using within that map to pick a second map to pull in the topics. It’s just cleaning it up with some nice map. Then I’m going through and adding some nice CSS and making it pretty.


Should you go on this journey and use it for your project? It comes down to any sort of coding situation of whether or not it fits your project requirements. If you need to go through and implement or what’s your use case for it, if you have Stack limitations, there are all those things of whether or not. As a front-end going into FullStack, I think it is an excellent tool that helps you with all the support. It also was intended to be built. The Facebook team made it. It was intended to be built with React. There are so many different ways that you can integrate it. You don’t have to use Vanilla JavaScript Fetch API. There are multiple clients and ways to pull in GraphQL. Many popular libraries are made to make it easy to interact with. Adobe Experience Manager has a built-in GraphQL if you want that GraphQL editor in API. They have a ton of tutorials on how to set it up, as well as WordPress does. 

GraphQL was intended to be used for front-end developers, especially since it was there to help simplify the ways to request answers with sometimes really complex and cumbersome data structures. It makes it easy to do a bit more without having to rewrite all your code. I’m always hesitant to jump into many FullStack projects or even do everything from the back end to the front end because sometimes it’s daunting to learn a new language or setup. Thankfully, with Node.js and Express or Fastify, you can easily do a server setup and then pull in cool things to GraphQL if you want to try something similar to Express.