Trilo

Lambda has an annoying limitation in that we cannot return HTTP response data, and then continue executing. This affects an event based system using Lambda, because a requester has to wait for a pushed event to travel through the system and the response to travel all the way back before getting an HTTP response which is a terrible user experience! It does however have the advantage that we know if an event has failed somewhere...critical for payments.

SQS allows the best of both worlds. A single (very fast) HTTP request to SQS to send the payload, then SQS deals with ensuring that the rest of the actions can complete.

We ummed and ahhed for a while over this. We definitely wanted a tight structure and relatability between tables which points towards SQL. The Aurora Serverless was a strong contender as it allows easy access from node via the aws-sdk. However we liked the very easy scalability of DDB, and most of the persistence work was executing on single entries containing a lot of fields which lends itself well to DDB. There are very few cases where we need to select a large list of items, and any complex queries are neatly scriptable in AppSync resolvers in Velocity. Going for Document over SQL was a very fundamental decision which has shaped how a lot of the API, and therefore the product, functions.

Having the Infra all scripted makes life far easier. We tried the SLS Components but felt uneasy not having a clear list of all the components. The CF auto provisioning/rolling back/etc, yes it's slow but it's incredibly solid.

We started with Gatsby as it allowed imports from outside the root directory. We soon wanted lambda server side rendering and switched to NextJS, and Webpack aliases.