homepage VS Previous Serverless Version 0.5.x

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.

Github | Website

i deployed a lambda and http api gateway using a serverless.com (sls) template as a start. I get the following error when it processes a specific request:

Have you tried serverless.com ? It lets you have infrastructure as code.

- With Lambda, you manage creating and building the container yourself, as well as updating the Lambda function code. There are tools out there such as sst or serverless.com which help streamline this.

If you'd like to use Lambda, usually you need to engineer FOR it, from day one, you don't (often) get to choose some other framework and shoehorn it into Lambda and Serverless. There's some great frameworks to help deploy code into Lambda easily and create REST endpoints for things, one such frameworks is serverless.com that helps easily deploy to it, but it lacks a framework for doing REST that also supports local emulation (as easily). For that, I recommend a framework by AWS called Chalice. This is an amazing REST framework that runs a proxy that works locally and deploys exactly the same on Lambda, it is Python however.

I use serverless.com for AWS stuff.

After knocking out a README with a set of goals and a list of TODOs to check off as I made progress, I spent about 10 hours over a weekend trying to get something to work. I used serverless for making Lambda easier, Github Actions for the deploy pipeline and store my credentials; and sadly I rolled my own access_token refresh logic because I couldn't find a helper that just did that for me! wtf!?

Does everyone who uses Workers just use wrangler cli and the cloudflare console UI for everything or is anyone using other tools like serverless framework (https://serverless.com) instead? Looks like they added some support for cloudflare but haven't tried it yet.