I have to be honest, my time with full stack web development has been short to say the least. Beginning just under a year ago — coding along to videos online, now halfway through my software engineering bootcamp journey — I’ve decided to walk through the process with you. Step by step, heavy with documentation and sprinkled with my very, very humble opinion.
If you are curious, here are some examples of popular back end frameworks:
1. Django — framework that is base on the language Python. Popular for larger projects, Django is used by National Geographic and Pinterest.
2. Spring Boot — based on Java, was built with the intention of being easy to use. Designed for application in large scale projects that work with cloud storage.
3. Flask — another Python based framework. Flask was designed with the intention of being more compatible with smaller projects. Maybe you could consider it the ‘younger sibling’ to Django.
Why use a Ruby on Rails API?
Have you ever visited a website, clicked a link and then waited (hopefully patiently) for the next page to reload? Normally with Rails, a developer would be producing HTML within their ‘view’ folders. Connecting these views together through various links and forms. The question stands, why force a user to continuously refresh your webpage when you have the capability to keep everything quick and easy. That is after all, the great thing about the internet right? Even Google shows you their response time every time you do a Google search. If Google is proud of it, it must be important.
Rails provides several aspects out of the box that still apply to API applications. Just to name a few: reloading, development mode, test mode and security. Check out the Ruby on Rails as an API documentation, specifically section II for more details.
The back end of any full stack application, could be considered the brains of the application. This is where the data will be stored, models created, relationships or associations made along with many other details. Rails defaults to using SQLite database, but you have the ability to choose another if desired.
The first step in creating a FSA(Full Stack Application), like anything else, is planning.
1. What is your base goal?
2. What kind of ‘objects’ or models will you need in order to accomplish your base goal?
3. Between those models, what kind of relationships do they have?
4. How will your site be structured?
Once the ‘blueprint’ for the application is set, through some heavy brainstorming and ample time consumption, it’s time to get those hands dirty!!!
** Keep in mind, it is important to separate your back end and front end in separate repositories(I learned the hard way) **
From your bash command line you can create a new Rails app just like you would normally, but with one small difference. Adding the ‘- -api ’ flag at the end of the ‘rails new’ command, tells Rails that it is being created to be used as an API. This flag essentially trims the fat off your Rails app, getting rid of unnecessary items.
In more detail, creating a Rails API will do three things:
1. Middleware for functionality within the browser will not be provided. For example, support for cookies would normally be included within the Rails app.
2. ApplicationController will inherit from ActionController::API. Normally, Application Controller would inherit from ActionController::Base.
3. Generators that may be used, will skip over the views portion of their generation. No more page reloading through links and forms.
Finally, before you begin to implement your project plan, the last step is handling CORS(cross-origin resource sharing). CORS gives a server the ability to identify other origins in which it might be able to retrieve resources from.
CORS does sound rather intimidating, but for the purposes of this blog:
1. Uncomment your rack-cors gem within the Gemfile.
2. Run bundle install, to make sure the gem is installed.
3. Within your config/application.rb file, and inside class Application < Rails::Application add the following:
Now we’re ready to go! Onward to the Front End!!!
Without diving too far into what goes on behind the scenes of your Ruby on Rails API, one by one — database tables will be structured, models created, and associations established.
Now, we are into the front of the the FSA. Previously, I mentioned that the back end serves like the brains of the application. Well, the front end serves as the skeleton, muscles and circulatory system of your application (who knew I’d be able to use my Exercise Science degree in an analogy to building full stack web applications, not me that’s who).
HTML (HyperText Markup Language):
MDN HTML elements reference
CSS (Cascading Style Sheets):
CSS is what gives your website life. I would say it is like the circulatory system of the human body. CSS styling will be held inside the index.css file within your front end directory. All websites would be rather boring or unorganized without CSS. Many find CSS to be the fun part of web design, but it is important to remember that CSS is, for the most part, aesthetic.
Here is an example of the power of CSS:
Can you imagine the internet without CSS. It’d be like living in the 90’s again. Actually, that doesn’t sound bad at all…
Wrapping it all together!
Continuing with my all too spot on analogy of a full stack web application and the human body, you can see how important all factors involved are. Much like your muscles wouldn’t work without a skeleton and blood vessels, your web application won’t behave through JS if there is no HTML structure or CSS styling to give it some personality. Most certainly, the three amigos (JS, HTML, CSS) wouldn’t know what to do without the brain (Rails API). Each part is a vital piece to the operation. One cannot go without the others in some way shape or form.
Much like an athlete would train their body for a sporting event, it is important as web developers that we practice our technique and skills to make sure we are giving the best we can to the internet.