homepage VS serverless-bundle

I highly recommend, with these types of credentials, go serverless and use https://sst.dev/ with https://nextjs.org/ . Stupid simple deployment, and SST’s (reasonably priced) paid arm, https://seed.run/, for ci/cd and deployment including great stage management, and nearly free logging and error observability.

I've used seed.run with the Serverless Framework for 4-5 years. As I don't deploy to much I've stayed with the free tier and it all works perfectly. Try it out it won't disappoint.

They have, at least SST, visit seed

The backend is built with serverless.com (lambda, dynamodb, sqs, appsync). The good thing is that all the backend is stored in a file and you can deploy multiple stacks on the same account using seed.run . You don't really need EC2/Fargate when you have lambdas and you know that most of the time will be idle time. The same with cache I wouldn't think of it right now until you see the workload you are facing. Dynamodb once you understand it and have a proper design it's the fastest thing you can have. On my appsync calls I'm using Dynamodb as a cache because it's cheaper...

I run my personal project on AWS. I has been running for 4+ years now and I never had a local environment. I took the serverless route. That is appsync, lambda, dynamodb, sqs to build the stack. I'm using serverless.com to have all the resources defined in a yaml files which will deploy multiple stacks. I'm using seed.run to manage that part because it's much more simple than to do it manually.

How do you deploy your services on AWS? I'm a solo developer and have no issues with my backend. I use the Serverless framework so all services, lambdas, configurations is on a repository on git. I do all the deploys to a dev environment where I test my code and later on I deploy with a PR to my prod environment thanks to seed.run.

Your repo setup can look different, but the general concept still holds true. You have to figure out if a file change affects an individual service, or if a file change affects all the services. The advantage of this strategy is that you know upfront which services can be skipped. This allows you to skip a portion of the entire build process, thus speeding up your builds. A shameless plug here, Seed supports this and the setup outlined in this post out of the box!

I use serverless.com framework with tests and deploy with seed.run. So I don't ever touch a Lambda in production. I also have 2 environments, one for testing and the other for production.

I'd use seed.run . You can deploy multiple stacks on parallel or with dependencies. You can deploy from github ( 100% sure ) from gitlab I'm not sure. Worth checking it. I'm using the service for free and haven't had any issue.

Building on top of it requires some knowledge but for me it has been worth it. I use serverless.com to manage all the infrastructure as a CF template. This has the benefit that I can deploy multiple test environments at will. I'm also using seed.run to do all the CI/CD ( also for free ) and doing all the monitoring with lumigo.io . And I build single pages applications that use Netlify.com to handle at that part. I do it to avoid less things to manage on AWS directly when the service is free (again) and really easy to use.

As you can see in the above handler.js file, we're getting CommonJS instead of modern JavaScript or TypeScript. To get these, you need webpack or some other bundler. serverless-webpack exists if you want full control over your ecosystem, but there is also serverless-bundle that gives you a set of reasonable defaults on webpack 4 out of the box. We opted into this option to get us started quickly.

One of the most important aspects of serverless development is keeping an eye on your bundle sizes and to reduce cold start times on Lambda. Keeping this in mind, the template utilizes serverless-esbuild and serverless-analyze-bundle-plugin to provide function analysis out-of-the-box. I opted for serverless-esbuild over serverless-bundle for a few reasons:

We use the package.json at the project root to install the dependencies that will be shared across all the services. For example, if you are using serverless-bundle to optimally package the Lambda functions, or using the serverless-plugin-warmup to reduce cold starts, they should be installed at the root level. It doesn’t make sense to install them in each and every single service.