gateway

I write Lambda functions in golang. In dev I run the function as local http server. In prod I map a custom domain to the lambda, routing is done internally to the function. API Gateway is only used for the top level route. This workflow is enabled by https://github.com/apex/gateway In principle I try to avoid Amazon Web Services that lock me into the platform. So, for my dev stack I run a few other containers to give me the equivalent of the prod environment, RDS (MySQL or PostgreSQL), ES (OpenDistro), S3 (Minio), and SES https://github.com/mozey/aws-local Dev is easy because I can test everything locally, and the resulting code should be portable to any other cloud. Obviously this approach might not be feasible if you choose to use AWS that do not have equivalent self-hosted options.

I’d argue that if you’re doing serverless right you should be abstracting away the particulars of the serverless provider and implementing your functions in an provider agnostic way. A good example would be using something like apex/gateway which simply proxies lambda requests to golang standard http handlers. Virtually elminating vendor lock-in. I think serverless has a place (yes even for business logic) but like anything you have to pick the right took for the job. Apex/gateway: https://github.com/apex/gateway

I’d prefer https://github.com/apex/gateway - same dev as Apex and Up so, I’d expect better support.