I use the serverless framework for simple REST APIs. This is especially beneficial if you're hooking into other cloud provider tools (such as S3, SQS, ect. with AWS).<p>The main reason is speed of deployment and overhead. I can push the code to a repo and boom -- a working backend with basically no infra config.<p>I've found this works very well for internal glue tools that aren't majorly affected by cold starts.<p>One nice example was building a quick and dirty internal tool for L3 support staff to alter certain client records. It wasn't appropriate to hand out DB access and it wasn't a high enough priority to create a new feature in our "real" support system, so I build a few basic endpoints (with strict rules) and passed it off to the team. They're using Postman to make the changes as needed (using a JWT for auth from our main application).
If we are talking about the ‘serverless’ framework.<p>I use it to stand up all resources for Amazon Web Services. The web gateway api, dynamodb tables, lamda code.<p>It is invaluable. Saves so much time. No need to standup resources by hand.
I use Cloudflare Workers for:<p>* Serving a standard security.txt file for all websites within my account<p>* Automatically rewriting the case of URLs for a CMS that doesn't support case-insensitivity<p>* Adding security headers to sites that don't support adding them locally (e.g. third-party hosting)<p>* Proxying requests elsewhere directly from the 'edge', rather than having to run my own proxy<p>* Serving static config files, e.g. mta-sts.txt, proxy.pac
Modern serverless platofrms include distributed data tiers like Cloudflare KV so theoretically at least the only problem domain they can't handle is secure communications and secrets requiring higher levels of auditing