Trilo

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.