Promoting HTTP APIs to the default #838
Today, and since the beginnings of Architect in 2016, the default API Gateway type has been
Earlier this year, API Gateway went GA with their latest API type:
To provide Architect users early support for
Some of my current findings about
I strongly believe we should maintain backwards compat for existing
Update, added a second idea:
And for existing
Update, added a second idea:
We are long overdue to reintroduce
Impacts of this change
Ideally little to none; if we poll existing resources, nothing changes for current projects; everyone gets more (theoretical) API deploy speed and a price reduction.
Ideally we do our backwards compat pre-deploy resource queries in
Likely only a minor impact; post-deploy URL queries may change.
Likely no (or only minor) impact.
Minor, most things stay the same.
The text was updated successfully, but these errors were encountered:
@jgallen23 per the
I guess if you are doing the detection (I missed that part), then maybe it doesn't have to be breaking, but then docs might get a bit confusing if both are the default but it depends if you launched arc previously or not. Seems easier to just say, as of 7.0.0, http api is default and no more production/staging urls and here's the new payload structure.
Otherwise, I'd say if this is an additive, forward compatible change, I'm not able to come up with any other reasons to bump major.
Think we can thread this needle and make this non breaking and additive as Ryan mentions. By making #architect/deploy a bit smarter it can check the type before deploying and branch the generated CloudFormation should RestApi fallback be required. Upgrading can be an additive flag. Would like to keep
Which I like. This means people with the existing 1.0 request/response payloads can opt into HttpApi whenever they want. New apps will be on the new stuff. Old apps can upgrade whenever. New apps can opt into the RestApi if for some reason they want to do that too.
For me, the big win here is for our new users. Currently folks are always troubled by RestApi trailing
I am a tad puzzled, because I remember having read this on Slack on May 13th 2020:
Now, only after 15 days, all the sudden HTTP APIs are good to go? (I personally I am okay to upgrade to HTTP APIs, don't get me wrong, but curious at the same time…)
FWIW, I too would like to see HTTP being the default also from a configuration perspective (promoting less additional config and more convention/default), so here's my take on how I'd see that happen:
What would happen to existing (REST) apps when HTTP becomes the new default:
Infer REST as @ryanblock suggested and nothing changes:
As an existing app what if I want to opt-in for the new HTTP (since I opt-in explicitly the fact that my app breaks is my responsibility and I'll make sure to fix it before deploying in production):
What would happen to new apps when HTTP becomes the new default:
Detect this is a new app (i.e. infer no previous REST API Gateway is present), so create HTTP.
About "once deployed, no longer needed" above:
Since opting in is a one-time only thing, perhaps it could be part of the
… or —with a more ambitious take— perhaps even
Although in both config and CLI argument approaches
We've been evaluating
Fast forward: as I feel is part of my responsibility to the project, I once again checked in on
While admittedly anecdotal (and downstream of some of the things I just mentioned, about
After some internal discussion, including deliberation on what we, as core maintainers, are ready to declare we'll support, I decided to seed this conversation. So from my perspective, this wasn't sudden, per se (although I take your point).
Re. migration, that makes sense – I think we'll probably need to have something in the
Re. backwards compat, I don't see an issue with continuing to maintain our existing REST API code paths – they've changed basically not at all for years, so we can take things as they come but I don't anticipate much reason to hard deprecate anything in the near term.
I really like the idea of making this upgrade a one time CLI flag. Adding more stuff to the
My view on this:
Other than that, I'm excited for the 70% price reduction
Heads up! First cut of this just landed in
There's still more work to do, but this now supports:
Unless you manually set one of those settings, whatever your API already is, it will continue to be that same API type.
Have some more hardening to do before I'm ready for everyone to jump in on testing, but please do feel free (and, of course, report those bugs).
Will check back soon with additional progress, including full Architect Functions support.