follow me

In this final episode of the series, we’ll take a look at deploying our Single Page Application to Amazon Web Services Simple Storage Service (or S3).

New year, new you blog post! In this long overdue part we’ll strengthen our command of loading data from the server and take a look at presenting it.

Last time we built an authentication mechanism with a pretty glaring bug - you can just set the token in localStorage to whatever and it’ll let you in. We need to actually read the token, and persist what we’ve read so we don’t have to do it over and over.

In this part we’ll allow the user to log in to our frontend app, using the auth mechanism we’ve built on the back end earlier. A lot of topics in this one, so jump right in!

Now that we have our environment running, the app is initialized, and we know a little bit about what’s going on in there, it’s time to take a little bit of time to design our front end.

Last time we’ve seen each other, we’ve just deployed our Rails 5.1 API app. Time to put an end to this! A front end, of course.

In this final part of our Rails API app series we’ll talk about specs, code coverage, continuous integration and deployment - and how to be certain your application is working.

Time to deal with authenticating users in our bookstore application.

We have two more things to tackle before our Rails API app is an MVP: namespacing the controllers and creating an authentication mechanism. We’ll tackle namespacing the controllers in this article - it might seem wordy, but it’s for a good reason.

Oh yeah. Now we’re going hardcore. Well, not really.

While Rails embraces a continuously changing data model, it’s always good to stop and think for a minute about the domain we’re trying to magically lockwithin an app. We’re building a bookstore. So what’s in one?