Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
LocalStack
đź’» A fully functional local AWS cloud stack. Develop and test your cloud & Serverless apps offline
-
-
-
Previous Serverless Version 0.5.x
⚡ Serverless Framework – Use AWS Lambda and other managed cloud services to build apps that auto-scale, cost nothing when idle, and boast radically low maintenance.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
> The ability to move between the frontend, backend, and infrastructure code without having to learn a different language is invaluable to every member of the team.
I'm actually quite skeptical of this claim. Learning a new language isn't really a big deal unless you are using relatively "esoteric" stuff like clojure or elixir which really require an experienced consultant to train your team.
With AWS Chalice, we've been able to ship production scale code (for govcloud) in Python without any one of us breaking the environment by simply using separate staging. We were able to get PHP/Javascript developers to use it with barely any downtime. In fact it was more or less appreciated from the clean and simple nature of Python right from the get go.
This feels like way too much engineering from the get go. Here's my workflow with AWS Chalice and its super basic (I'm open to improvements here).
- checkout code from github
- run localhost and test endpoints written in python (exactly like Flask)
- push to development stage API gateway
- verify it is working as intended and this is when we catch missing IAM roles, we document them. if something is wrong with our AWS setup (we dont use CDK just simply use the AWS console to set everything up once like VPC and RDS)
- push to production stage API gateway
All this shimming, typescript (rule of thumb is ~40% more code for 20% improvement through less documentation and type errors, only really valid in large teams) separate AWS developer accounts seems overkill.
The one benefit I see from all this extra compartmentalization is if you are working in large teams for a large company since you are going to discover missing IAM roles and permissions anyways and is part of being an implicit "human AWS compiler trying different stackoverflow answers".
Some positives I see are CDK but if you are deploying your infrastructure once, I really don't see the need for it, unless you have many infrastructures that can benefit from boilerplate generation.
Happy to hear from all ends of the spectrum, serverless-stack could be something I explore this weekend but there's just so much going on and I'm getting lot of marketing department vibes from reading the website (like idea to ipo and typescript for all) and to top it off
going to https://docs.serverless-stack.com/ triggers an antivirus warning about some netlify url ( nostalgic-brahmgupta09582d1.netlify.app) what is going on here???
This was an interesting read, I’m currently facing a similar set of decisions. Good on you guys for finding an approach you’re excited to write about!
Throwing my two cents into the conversation, perhaps one day we’ll be able to have our cake and eat it too: If http://localstack.cloud (replicate AWS services locally) ever makes it to a 1.0 release, I may strongly think about vendor lock-in friendly approach like this. Unfortunately localstack recently (v0.14.1) forced me to give up on each ambition in my ideal develop-n-test-it-locally wishlist: first I gave up on a CDK provisioning resources locally, then I abandoned using ECR images for localstack lambda, and then I abandoned localstack altogether. Their S3 mock still works for local dev though!
The other thing is... if you want to develop locally but still on top of lambda, you either skip the api gateway altogether, or you write an undeployed shim for like expressJS or node http to fake that restful pattern locally. As great as not using APIGW+lambda-integration is, Lambda doesn’t believe in return codes other than 200 (ignoring throws and server failures), and you should probably use the AWS-sdk/client-lambda package. This all scatters weird lambda anti patterns. Yuck, that’s gonna be a big “chore:” commit if you ever get sufficiently sick of it. And I’m actually not in favor of using the lambda response interface, but APIGW lambda integrations are a seeming sht show. VTL and selection pattern seem so bad I’d rather just have more Kubernetes experience. Knative is good these days, I hear.
GCR is certainly very good. Note that there are quite a few good alternatives too:
fly.io - https://fly.io/
Digital Ocean App Platform - https://www.digitalocean.com/products/app-platform
Scaleway Compute Containers - https://www.scaleway.com/en/docs/compute/containers/quicksta...
serverless-offline (https://github.com/dherault/serverless-offline) is a great tool to use for local development of serverless applications.
It's not a complete mirror image of what you get but it's close enough in my experience.
