Tobin Chew

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.

It has a much easier to use browser email builder which our non-tech designers can use. Sending is just with a POST from a lambda.

Keeping DNS in AWS makes it all WAY easier to integrate with AWS endpoints, and creating free SSL certificates automatically in deployment pipes.

Like the easy integration with IAM profiles, and easy integration with code pipeline. Also it's free for private repos.

For rendering and API logic we opted entirely for lambdas. There is a fine line between where do you split routing between APIG and Lambda. In reality the lambdas contain a lot of the same imported code so perhaps we could argue it'd be better as a containerised system. We liked how you can very quickly update a single lambda from SLS, and the lambda deployment options are extensive. Our business logic is complex so removing having to deal with deployment and operations has been the biggest benefit timewise.

We started in Amplify but switched to SLS. Services in the Amplify ecosystem always feels about 80% done; as we expanded we would reach a point where the required functionality was not there yet (but coming soon in the git comments). Trying to manually add it in yourself was difficult as Amplify was quite opaque and had a habit of overwriting things.

Serverless has its teething problems and when V2 came out we had to stay in V1 for a long time as the plugins were not compatible yet.

Across the dev team we use both so we can test as many environment combinations as possible.