Last year, the #LMF team built a prototype of MAAT, a smartwatch tool to help cognitively challenged children and adults adhere to a daily schedule, an idea from teacher-turned-entrepreneur Esther Goossens.
This month, we worked on turning that prototype into something that was production ready in order to release it to a wider audience. One of the main things that needed to happen for that was rebuilding the back-end API. This had previously been built on an internal PHP framework that is no longer maintained, and wouldn’t be suitable for further development.
We only had two days to build that new backend. As with most of our recent projects, we decided to go for AWS Lambda, DynamoDB and the Serverless framework. Here’s how we did it.
Modelling the table
I remember being so confused about single-table DynamoDB database design when I first learned about it, coming from a SQL-background, but am happy to see that with every database design we do, modelling goes faster and easier, and this one only took us about 30 minutes to think over and write out.
Since we already had a API specification, there was a clear list of database access patterns available. We reviewed them and made some small adjustments to the endpoints list based on learnings from building the prototype and ideas about upcoming functionality.
From there, we started modelling the table in a Google sheet. I always start with the same four fields:
pk, sk, type, id
typeis a simple string describing the item type, partially to help with deserialising and human readability.
idis always a unique UUID. In the future, we might switch to using ULIDs to help with chronological sorting where necessary.
sktogether form the table’s primary key (hash key). By default,
pkwould be formed by combining the type with the ID, separated by a hash symbol. The
skwould be the user’s ID. We then further customise this based on the access patterns per entity type.
After we’ve looked at access patterns and added attributes:
A few weeks ago, I built a little tool to scaffold Serverless Node.js projects. We added all of our API endpoints in there, downloaded the ZIP, inited a Git repo and set up CircleCI.
The scaffold comes with some unit test scaffolding as well. We didn’t manage to get up to 100% code coverage during our 2-day sprint, but we did write unit tests for the more complicated parts of the business logic in the API.
API Gateway v2
We also used the new HTTP APIs in API Gateway. That made it very simple to add JWT token authentication with just a few lines of config in our
We used Cognito user groups to regulate access, so that we can generate multiple users per account/organisation.
To speed up building authentication, we used AWS Amplify’s React UI for login and signup, which allowed us to have authentication in our web app implemented in less than an hour.
We were able to crank out a complete API with about three dozen endpoints, mobile push notifications, scheduled events and authentication in two days.
The best part: that new production environment literally doesn’t cost anything, until customers start using it.
I don’t think that’s possible with anything but serverless!