Building a performant real-time web app with Ember Fastboot and Phoenix (Part 2.1)

Some small adjustments to your API

This article is part 2.1 in a series. You should first read the previous parts in this series, or it may not make much sense!

Part 1: The meeting of two well-aligned, opinionated frameworks
Part 2: Users and Authentication (API)
Part 2.1: Some small adjustments to your API
Part 3: Users and Authentication (UI)
Part 4: Logging in to our API & ember-simple-auth
Part 5: Building a CRUD resource
Part 6: Animating your UI with liquid-fire
Part 7: Room UI & Messages

As I began writing part 3 of this series, it became clear that a few small adjustments needed to be made in order to make things as easy and straight-forward as possible. This is not to say that all of these things made moving forward impossible (or even difficult) — just unnecessarily cumbersome and distracting for our purposes.

User Registration

We want to align our user registration API endpoint with JSON-API standards, and that means “dasherizing” attribute names. Please update your web/controllers/registration_controller.ex create method so that it looks like this.

If you were following from Part 2, here are the changes you’ll need to make

We then need to add a 403 error to our ./web/views/error_view.ex. It will look very similar to the existing 401 error

A resource requiring authentication

It’ll be useful to have some API endpoint that requires authentication as we begin to build our our UI. Why not the currently logged-in user?

The API endpoint will be

GET /api/user/current

and it will return the JSON-API document for a User object.

The first thing we’ll need to do is make a new pipeline in our router, for requests that require authentication credentials. This will do two things

• Ensure that credentials are passed in the Authorization request header, and that the credentials were signed by this server
• Load the resource specified by the credentials (the user) into memory

See the api_auth pipeline below

api_auth pipeline for authenticated requests

We’ll then need a controller to handle these authenticated requests, but first we need one more thing — An error handler to delegate failed authentication situations to. Create a new file web/auth_error_handler.ex like this

You’ll notice that this is a controller — that’s just so we can have it directly render errors via the ErrorView.

Now we can create our user controller. Make a new file web/controllers/user_controller.ex that looks like this

This essentially just retrieves the user Guardian is already loading for us, and renders it out through the UserView. The plug we’ve applied using Guardian ensures that only authenticated users will be able to invoke this new create method.

Finally, let’s wire up this controller to our router. Your web/router.ex should now look like this

Great, you should be all caught up now. One last thing we’ll want to do is modify our Procfile so that database migrations happen automatically whenever our server starts up. Open up your Procfile, and make sure it looks something like this

web: elixir -S mix do ecto.migrate, phoenix.server

Open up a new PR to your master branch on GitHub, and when tests pass, merge it in. Our API is ready for us to begin the UI portion of our authentication.

If you’d like to compare your code to mine. Here you go:

Migrate automatically · mike-north/peepchat-api@93e7c58

All done! Grab a 🍺 from the fridge and strap in for Part 3, where we’ll start working with Material design, and build out the UI side of our user registration feature.