Upskill/Reskill

In this tutorial, we’re going to generate a useful app while compiling a few wonderful technology tools – and having some fun with development along the way. To build our new real-time chat application we’ll be using GraphQL, MongoDB, Node.js, and most importantly ReactHooks. This app will offer users the ability to view all of the other online users once they have logged in, so they can chat with anyone on the platform. There will also be a feature to notify users when new members log in or if the person they’re chatting with is actively typing a response. Sound like a good plan? Awesome, let’s get going! During my early days as a web developer, I stumbled upon GraphQL. I was searching for a tutorial on a full-stack development tool, and the most recently posted video happened to be about GraphQL. I pushed play and watched the tutorial, without any real background knowledge of GraphQL, how it worked, or what the options were for other similar programs. I probably don’t need to tell you that this method of learning came with a few bumps in the road. I worked my way through by looking over available explanations of GraphQL online and pouring over the few available answers to questions posted on StackOverflow regarding GraphQL. It surprised me that there weren’t more resources available about GraphQL, especially considering how useful it can be. Putting out this article is my way of giving back to the dev community I’m lucky to be a part of, so that you can maybe learn faster than I did. This is the beginning of a two part tutorial in which I will discuss designing the server. I am not going to go into great detail on the tech stack, because I do feel that there are plenty of resources out there that could do a better job. The next installment of our two part tutorial will take you through building the frontend of the app. So, let’s get to the fun stuff. I’ve posted the entire code for the app on Github, so if you’re interested feel free to check out the code by cloning the repo: Because this is such a simple app, we’re going to use a simple file structure to house it. Once we’re done, the server file structure should look like this: Configure server For this configuration we’ll be using GraphQL-yoga. GraphQL is an easy to set up fully-featured server. It was created by the developers at Facebook as an alternative API to REST. It also functions as a runtime used to fulfill queries. The APIs that are coded using GraphQL, as opposed to REST architecture, provide clients the function of asking the server for specifically what they need from the database. As a result, they get what they want and nothing more. Isn’t that sweet? We’ll also be using mLab as well as the Mongoose library. If you prefer to use a local instance, you can install it on your local machine by referencing the MongoDB official docs. I plan to use mLab instead since the app will be hosted on Heroku. mLab functions as a database-as-a-service provider for MongoDB. Using mLab you can access free MongoDB databases through the internet. If you need help setting up mLab, look here. Now, in order to install the dependencies we’ll need for the app you should initialize npm. Import the following dependencies into the index.js file. We’ll be using GraphQLServer, a core primitive provided by graphql-yoga, to make an instance of the server where all the building will take place. The server created will automatically be configured with all related features of GraphQLschema along with many basic server configurations. In order to make our app real-time, we will be activating withFilter and PubSub as subscriptions within GraphQL. We’ll talk more about this later. ‍ The next step in our chat app is to connect your database to Mongoose. If you aren’t successful within the first two arguments you will get depreciation warnings from Mongoose. Models Next, you should pass your schema into the new Mongoose models you create. Because the app we’re building is relatively simple, you’ll only need User and Message models. Go ahead and include these in the models.js file: We’ll be using email addresses to identify our users, so each email input must be unique. Also, we need to make sure that both name and email fields are required. TypeDefs There are a couple of ways we can input schema into our GraphQL server; we can input schema manually or we could use typeDefs and resolvers. We’re going to go with the latter for this tutorial. TypeDefs is a program to define the schema models we want included and specify what the contents of each model should be. Along with defining the structure of the GraphQL API (written in GraphQL SDL, Schema Definition Language), they also dictate the GraphQL operation types we would like to have. There are three operation types available in TypeDef – queries, mutations, and subscriptions. The Queries operation type is used for requesting data through the R-Read in the CRUD functions. Mutations allow us to make changes, or mutate, data in our models. They account for the C-Create, U-Update and D-Delete CRUD functions. Both Queries and Mutations have specific entry points into the schema. Subscriptions are used for creation and maintenance of the constant connection with the server. If you’d like more information, check out this source and this source. Go ahead and make a typeDefs.js file and insert the following code (don’t forget to include the backticks): Now we’ve successfully defined Message and User types along with the operation types we discussed earlier: query, mutation, and subscription. These are each considered object types and as such are the simplest components of GraphQL schema. Using these, we’ll be able to define what the program should fetch from the server. Note that these functions are not limited to a Node.js backend because they are language agnostic. Pay particular attention to User – you should notice that it contains a field for messages. This allows us many message options depending on the specific user we query. The message field also includes a reference to the user it was created by so that we can connect the messages created to the user who sent them.