Tuesday we were handed a project with a fully functional and built backend — Rails — and required us to build out the frontend — JavaScript — for a web API.
It was a stressful project with lots of guesswork, Google, StackOverflow and trial-and-error — which some may argue is a typical day as a software engineer. I’m writing this in the hopes it may be useful to others being slapped in the face without sufficient guidance, like those learning by themselves online.
An Application Programming Interface (API) is how applications communicate with one another. JSON, on the other hand, is the format of how applications collaborate with one another. These two terms are usually used together or within the same frame of reference. We are specifically dealing with just web APIs at the moment.
Before moving forward, it would be a good idea to brush up on the following:
- HTTP Requests and Verbs
- Model-View-Controller (MVC) Architecture
- JavaScript — Fetches, Promises, Callbacks
- Ruby on Rails — Active Record
- CRUD Actions — Create, Read, Update, Delete
- RESTful URIs / URLs
So what do I wanna talk about? I want to clarify the connection between the frontend and the backend — using JavaScript and Rails — so it is easier to grasp for others whom were in my position earlier this week.
The Backend with Rails
If we’re following RESTful URLs, CRUD actions, and the MVC architecture:
- we have routes defined for our web application
- we have the models built out with relationships defined
- we have the controllers with respective CRUD actions rendering JSON
- and we have the database created, migrated and seeded with some data
Once you have this basic setup complete, you will be able to run a server with rails s or rails server, and then go to the index page and see your seeded data. You can navigate around to different show pages as well. This is a good spot to note that we have no view files except the generic layout folder and it’s files.
I don’t know about you, but learning Rails with MVC I was sort of under the impression that the view files were the web pages themselves and that the routes simply defined the URL for them. I now believe that is invalid. Working with an API via Rails and JavaScript has opened my eyes to this realization!
The Frontend with Vanilla JavaScript
Some assumptions:
- working with Object Oriented programming with JavaScript
- therefore we have individual JS files for each model
- and an adapter file to act as a controller to communicate with the API
- but also any web page files — the HTML kind
We were split up into groups of 3 for this project I spoke of earlier, and during our time pair programming we came across an interesting phenomenon! Our team member was navigating and suggested we use the instance ID as a fetch option parameter to delete the instance from the API, database and the web page itself. I stated it this way on purpose!
I believed the API, database and the web page were all separate entities and they are. But when the instance was deleted, I started to doubt myself. A team member was sure that it wasn’t some black magic and that everything was well connected to ensure it would work — how it was connected and worked, he too was unsure.
Insert Diagram
If you made changes in the database, it would be automatically reflected in the API. Then you can make a fetch request to get updated information, which can be tied to the load of the DOM or web page to ensure up-to-date data from the backend.
TL;DR
- A web API is connected to the backend database and changes are automatically reflected in the API and the database
- Using vanilla JS you can CRUD the API which therein-fore affects the database to reflect the information on the frontend
- It pays off to pay attention when learning the foundations as it all comes full circle — HTML requests, MVC, REST and CRUD
