Understanding the Frontend/Backend Relationship

Wrapping up my first backend focussed Bootcamp phase, I struggled to solidify my understanding of the relationship between frontend and backend. In short, like so many relationships out there… it’s complicated. But I’ll try my best to explain (on a very simple level) how this relationship works.

A couple of disclaimers:

1. This blog is assuming you already know how to build a basic Frontend and Backend separately but need help connecting them. You also need to know how to allow CORS so that your Frontend can fetch to your Backend. This blog is NOT a tutorial on how to build a Frontend and/or Backend.

2. It is difficult to adequately display how all of the methods are being used and working without building out different components, which frankly I don’t have time to do. For this reason, the Frontend examples below should not be taken as a literal interpretation of what a Frontend should look like. I placed functions in places where they would normally be passed down from other components, and also did not include where the data being passed into the methods is coming from. The point of this walkthrough is to help gain a conceptual understanding of the relationship between Frontend and Backend.

Let’s start by looking at our backend. We have a Dog class and have migrated a dogs table that will contain the names of dogs.

Then, in our application_controller.rb, we define some routes for GET, POST, PATCH, and DELETE.

These are four relatively simple routes and shouldn’t look too complex. That being said, although the code within each route seems relatively simple, how are these routes utilized from the frontend? At least that's what struck me when looking at routes like these for the first time. My initial thought was that when we want one of these things to happen through the frontend we would somehow create an onClick or onSubmit that would reroute the page to one of the routes defined above while also somehow passing in data. If that hurt your brain trying to understand all that, that's exactly how I felt while trying to figure it out.

After some more learning, I had my big AHA moment — these routes are used within a fetch on the frontend. Maybe that was obvious to others from the start, but once that clicked for me it all started to make sense.

Now let’s take a look at what our Frontend might look like and how it can utilize those routes.

Notice that we aren’t fetching to the local host for our frontend (3000), we are fetching to our backend! Take a look at the GET route we defined above. All that route is doing is getting all the dogs from the database and then returning them as json. So on our frontend all we need to do is fetch to our backend with that route and voila — we have our dogs! Now we can set a state with them and pass them down to whatever components we need to.

We can see that all the post route defined in our backend is doing is creating a new dog using the parameters that are passed in.

Keep in mind, these functions would be defined and passed down from other components- I just put them together here for the visual. Assuming we have some kind of submit-form that can take in a new dog's name, we can add the dogSubmit function as an onSubmit to that form, and have it take in whatever name was passed in. Take a look at our ‘post dogs’ route defined in our backend — it's taking in whatever we give it through the posted route and creating a new dog in the database!

Arguably the most difficult method, this is definitely not how it would look in a real app… but hopefully seeing the different pieces in one place will help us gain an understanding.

Our GET and POST methods both dealt with all dogs, while our PATCH and DELETE will deal with only one- that's why these next two routes include a dog's id. If we look back at our patch route, it’s pretty simple on that end. It searches for a dog with an id that matches the id being used in the fetch, updates that dog's name to the name being passed into the PATCH, and then sends it back to the front. Then on the frontend side, we take that response and use a pre-defined function that will replace the old dog with the updated one.

Lastly, we have our DELETE method.

Like our PATCH, this method is searching for a dog by the id being passed in the fetch. But instead of updating it, this route is simply deleting the dog with that id. It then returns it to us where we can call our own deleteDog function on the id to remove it from our dogs.

While this definitely wasn’t a full-on technical walkthrough of the Frontend/Backend relationship, I hope that I demonstrated how the relationship works conceptually in a way that was at least somewhat helpful.

I’ll just end with something my instructor taught us when we first started ruby-

There are definitely times when Frontend vs. Backend coding feels like this

and while Frontend coding might be more fun in many ways, the backend really is much simpler in many ways. Just think about how much code an app could need on the Frontend vs how simple it can be on the Backend (especially with all the tools that exist to make it easier than ever). While I’m definitely not saying that I’d rather be a Backend developer, I’m definitely starting to understand why someone might!