Building Tasty Node.js APIs — Part 1: Our Architecture
What is required to make an API service?
- API — gatekeeper to our data, the interface between application programmers and our database
- Database — where our data is stored and retrieved later
- Host — where our API actually lives
Technology Stack
- Node.js 7 — friendly, supporting the majority of ES2015 features such as destructuring, Promises, and template strings.
- Why not GraphQL? REST is simple, and works widely with the web and mobile app front-ends staples. For doing things simply and flexibly, REST does the job.
- Database — DynamoDB is cheap, scales easily, and needs no maintenance
- Hapi — battle tested at Walmart, Hapi provides a solid suite of features with less configuration and better code reuse than Express.
- Ava — Makes testing really easy whilst running faster than its competitors
- Now — The most straightforward, friendly way of deploying servers with real domains and real HTTPS.
Button template maker
We will be creating a SVG generator, that given a phrase, theme, and size, will generate a button graphic.
New themes will be able to be created and saved, where they can be used for future buttons.
Models
Content modelling is the process of working out what sort of information your application will work with. It’s usually associated with creating schemas for databases, however as a general process I think it sits more at the level of design. So it’s helpful to try and think of your content model as early as possible.
Our application will have buttons, with the following sub pieces of information needed to create a button:
- size (e.g. large)
- text (e.g. Node 7)
- textColor (e.g. #2912a3)
- backgroundColorTop
- backgroundColorBottom
- borderColor
- borderWidth (e.g. 2.0)
- cornerRadius (e.g. 3.0)
All except text and size will actually belong in a theme, so that we can create a great look for a button, and reuse it with different text.
This results in two models:
button
- size
- text
- theme
theme
- textColor
- backgroundColorTop
- backgroundColorBottom
- borderColor
- borderWidth
- cornerRadius
Storing information
Our buttons will be created on the fly. Someone will be able to ask our API for a button with a certain size, text, and theme, and will receive an SVG that they can use in a web app, website, or mobile app.
Themes are not on the fly. Instead, their value is for a harmonious set of colors to be saved together and then used at will.
Saving them requires storing them somewhere, and since they are small, a database is a perfect fit. If the amount of information you wanted to save was one megabyte or even larger, then a service like S3 would be a better fit. In our case, it’s less than one kilobyte (a thousand times smaller), so storing it directly in the database will suffice.
Create, read, update, delete
We want to store themes, and so will require a few different actions to work with them.
First, we want to be able to create new themes. We should be able to create as many themes as we like.
Second, we want to be able to retrieve themes back later from the database, or read them. Like in a spreadsheet, we can just remember which row a theme was in, and then later scroll down to it and see all of its information such a text color, etc.
Also, we want to easily see all the themes we have created, like reading through every row in a spreadsheet.
Next, we want to be able to change a theme. If we decide it should have different colors, we can update it.
Lastly, when we decide a theme is no longer needed, we can delete it.
These actions are commonly known as create, read, update, and delete, or CRUD for short.
Interested in more?
Let me know by responding, or by emailing hello@icing.space!
