Plan Your Admin Dashboard
Shoppers are able to use our store right now, but we don’t know how many shoppers are online, what they have in their cart, or where they are in the checkout process. With this information, we will be able to know how well a launch is performing—maybe the demand is more or less than expected and the launch needs to be adjusted.
In this chapter, we’ll build a dashboard for Sneaker23 admins that provides live store analytics. Our dashboard will have the following features:
- Show the count of unique shoppers.
- Show the count of shoppers based on the page they’re on.
- Show the count of shoes that are in an active cart, by size.
- Restrict access to admins only.
We’ll start, in this section, with a plan for how we’ll go about building our admin dashboard. Let’s jump in.
Turn Requirements into a Plan
We’ll use the access restriction techniques covered in Chapter 4, Restrict Socket and Channel Access to restrict access to our dashboard. Our admin dashboard needs a higher level of restriction than the previous chapters’ features, so we will create a dedicated Socket for it. The following figure shows our Socket and Channel structure:
The Admin.DashboardController is in charge of authentication and Phoenix.Token creation. We will use HTTP basic authentication for our project, but a real-world application could easily use a different type of authentication. The client will use its provided token to connect to the Admin.Socket. The Admin.Socket only allows admins to connect, so we do not need to add topic authorization to the Admin.DashboardChannel.
The other requirements will prove more complex to build. We’ll leverage a Tracker to know how many shopping carts are connected. Each ShoppingCartChannel will track itself in the CartTracker when the Channel connects, and this data will be read by the Admin.DashboardChannel to build the user interface. The tracker setup will look like the following figure:
We’ll cover what Phoenix Tracker is and how it keeps data in sync across a cluster. Before we can do that, you will need to set up your project so that you can easily add this chapter’s features to it.
Set Up Your Project
If you’ve been following along in part II, you have a shopping cart in your Sneakers23 application that satisfies the acceptance tests from the last chapter. For this chapter, you can either start with a completely fresh application base, or you can use your existing project. Choose the next section based on what you’d like to do.
Set Up a Clean Project
Make sure that you have a copy of this book’s code, using the instructions found in Online Resources. Next, copy the base application into a development location.
| | $ cp -R code/location/sneakers_23_admin_base ~/sneakers_23_admin |
| | $ cd ~/sneakers_23_admin |
| | $ git init && git add . && git commit -m "initial commit (from base)" |
| | $ mix deps.get && mix ecto.setup && npm --prefix assets install |
If you don’t have the hello_sockets project, copy the following folder for the Tracker example that we will write shortly.
| | $ cp -R code/location/hello_sockets_without_tracker ~/hello_sockets |
| | $ cd ~/hello_sockets |
| | $ mix deps.get && npm --prefix assets install |
At this point, you have a clean codebase ready for this chapter’s admin dashboard. You can skip to the next major heading now—we’ll go over what Phoenix Tracker is.
Set Up Your Existing Project
If you want to use your existing repo, you simply need to copy a few files in—these files would be tedious to type otherwise.
| | $ cp code/location/sneakers_23_admin_base/assets/css/admin.css |
| | your_project/assets/css/admin.css |
| | |
| | $ cp code/location/sneakers_23_admin_base/assets/js/admin/dom.js |
| | your_project/assets/js/admin/dom.js |
| | |
| | $ cp code/location/sneakers_23_admin_base/index.html.eex |
| | your_project/index.html.eex |
You’re now ready to build this chapter’s admin dashboard. Before we do that, let’s go over what Phoenix Tracker is.