From Prototype to Production in one weekend using Serverless

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.

Image for post
Image for post

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

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

  • Attribute type is a simple string describing the item type, partially to help with deserialising and human readability.
  • Attribute id is always a unique UUID. In the future, we might switch to using ULIDs to help with chronological sorting where necessary.
  • Attributes pk and sk together form the table’s primary key (hash key). By default, pk would be formed by combining the type with the ID, separated by a hash symbol. The sk would be the user’s ID. We then further customise this based on the access patterns per entity type.

Base model:

Image for post
Image for post

After we’ve looked at access patterns and added attributes:

Image for post
Image for post

Project scaffolding

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 used Cognito user groups to regulate access, so that we can generate multiple users per account/organisation.

Amplify authentication

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!

Written by

Entrepreneur tech kid, co-founder of NearSt, Londoner, open source enthusiast and aspiring spare time literature geek.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store