Jumping Between Front-End and Back-End (React and Ruby on Rails)

Background

As a blooming full stack developer, one needs to have a thorough understanding of the front-end code and the back-end code. For my case, the front-end code is React, a framework based on Javascript, and the back-end code is Ruby on Rails, a framework based on Ruby. Although its important to understand the programming language/framework that I am using, I also need to fully understand how the front-end communicates with the back-end code. Otherwise, am I really a full stack developer?

React (and Vanilla Javascript)

React is a framework for front-end code, which means it directly interacts with the client. The client may want to input new information that comes from the back-end server, normally an API, which means that somewhere on our front-end code, I will need to make a request to the back-end server to give the specific information that the client is posting. In React, and luckily in vanilla Javascript, the means to do that is a fetch request. This link here will provide the full documentation of a fetch request. The code below is an example of said request:

The first argument is the URL that I am making the request to while the second argument is the type of request I am making. In the headers hash, for “Content-Type”, the type of data I am sending is in JSON format. The body hash is the data itself that I am sending. For the JSON.stringify(), this link explains what that function does. Now I know what the data itself that I am sending as well as its format. The next question is, will the back-end server accept this?

Ruby on Rails

For the most part, if you are using an existing server, there should be a README file that instructs developers how to format the specific data and the data itself to what the back-end server normally accepts. For this example, since I created an API from scratch with Ruby on Rails, I had the liberty to choose the type of data to receive, assuming Ruby on Rails has that capability. The most common format I have seen thus far is JSON format. For simplicity, I followed the RESTful routes convention, which can be explained more here.

In the fetch example above, at the end of the first argument, it ends with “/students” and the method in the second argument, also commonly referred to as the HTTP verb, is “POST”. Based on RESTful routes, this is used for creating a new student (as intended by the client). This RESTful route will then go into my Student Controller and to the “create” action, which is shown below:

Now that the information (first_name: “John”, last_name: “Smith”) is passed into my back-end server, the next step would be to create and persist this data in the back-end server, which is shown below:

You can assume that a Student model is already exists and functioning properly.

The information was passed into the back-end server and stored within the params hash. For relevance of this blog post, all you need to know is that the params hash is natively built into Ruby on Rails and that it acts as the medium to pass any input information to the Rails controllers.

In line 4, a new Student is created and persisted in the API and stored as a variable @student. In line 5, the @student variable is rendered into JSON format. You can think of this as the “response” from the back-end server. Although line 5 is not required by any means, it usually is good practice to render some sort of “response” as confirmation that the creation was successful (or not). This “response” can now be manipulated in the front-end. We don’t need to create a new function to this but rather extend on our fetch example to do so.

Lines 12–17 are the .then() functions that can manipulate the data into however I want. An important note that makes this plausible is line 5 in the Rails example, “render json: @student”, and line 4 in the fetch example, “”Accept”: “application/json”. In the Rails example, I explicitly stated to render the @student information into JSON format. In the fetch example, a key of the headers hash is “Accept” whose value is “application/json”. This key-value pair allows the fetch to receive data in the JSON format. This allows communication from the back-end server to the front-end to transmit information between each other.

Abstracting the Front-End, Back-End Flow

The process that I went through to have React and Rails communicate between each other can be abstracted between any front-end and back-end. Each step can also be correlated to my example.

Front-End to Back-End:

1. How does my front-end send information? In React, this can be sent via fetch with a method of “POST”.
2. What format does my back-end server receive? Rails can receive information in the JSON format.
3. Can my front-end manipulate the information into a format for my back-end server? Yes, via headers: {“Content-Type”: “application/json”} in my fetch.
4. How does my back-end server receive the information? In Rails, it stores the information in the params hash.

Back-End to Front-End:

1. What format does my front-end receive? React can receive in the JSON format via headers: {“Accept”: “application/json”} in my fetch.
2. Can my back-end server manipulate the information into a format for my front-end? Yes, via render json: @student.
3. How does front-end receive the information? As a Promise after my fetch completes.

Key Takeaway

For the most part, any deliverable can be abstracted and broken down into steps. Each step should have a clear and concise “mini-deliverable” that builds into the original deliverable. If a “mini-deliverable” isn’t possible, double check your assumptions and if that fails… there’s always Stack Overflow!