Building Consumer Apps Part 4: Into The Weeds
Welcome to Part 4 of my series on building consumer apps. In the previous three posts, I discussed many of the strategies, technologies, and techniques I use to build early stage apps. If you’re new to this series, check out Building Consumer Apps Part 1: Cooking Up A Great App first, because it’s about to get crazy in here.
In this section, I’m going to talk about the inner workings of the server and client when a user makes a request in my fictional app called CookMe (in this case, wants a list of all of their recipes), and actually implement it in Go and React. Also just a disclaimer, the code is meant to provide context, so it hasn’t been tested to be working and in some cases may not be “correct”.
OK, grab some coffee, keep your seatbelts fastened, and your tray tables in their upright and locked positions! Unless you need to set your coffee down. Then I guess you can lower your tray table.
The Server Request
Let’s assume our database and server are already up and running locally. Here’s the Go code that will get called on the server when the user asks for their list of recipes (the files are abbreviated, so they won’t work on their own):
All right let’s step through this:
- Their are two files for the recipes package, a controller and a model, to keep the code nice and separated. The code in the controller isn’t going to change, the only thing that will is what gets returned by the model (for example, one day we could return all the recipes and how many times the user had made that recipe, if that was being tracked).
- There is one endpoint, which is going to be a GET request, and the path for the endpoint is “/recipes”
- The endpoint has a pointer to the router. I’m using the Ace router, but there are plenty of options out there.
- The x-user-id is an HTTP header that’s going to get passed into every request for authentication purposes, so there’s no need to include it as a parameter in the API. We just ask for it in the header information.
- The controller asks the model to return an object, which is either going to be some object containing data or an error.
- We could add a check, which I left out on purpose, to prevent the server from panicking if it gets something it can’t handle.
Then in the model:
Here’s what it’s doing:
- Gets a pointer to the PostgreSQL database
- The SQL query gets performed and returns some recipe IDs
- It passes back the names in the response for simplicity, but we could pass back the entire recipe object (with ingredients, directions, prep time, cook time, etc.) if we wanted to display additional information.
Sweet, let’s test that the endpoint works. I use Google’s Advanced REST Client to test requests. If it worked, it should look like this:
The Client Request
This can be used for any GET request, and includes header information that would need to first be stored in cookies (remember, we need that userID to make the server request). Now all we need to do is make a controller file that will call the endpoint:
BOOM! The client and server are now on speaking terms. Isn’t that nice?
Of course, we’re not done. We need to set up a React components that will call the method and then show us some lovely recipe cards.
It’s going to be two components — a container and a view. Check out this great article by Dan Abramov, who works on the React team. Basically, the container is going to act kind of like a model, getting the data from the server:
The view component is a layout object that doesn’t really “know” how to do anything except display whatever it’s told to — in this case, a grid of recipes:
How are you feeling? Does your head hurt? Did you forget to lower your tray table and spill coffee all over? Hopefully not.
In Part 5, I’m going to talk about user authentication.