there's also this event-orientedness of serverless stuff that I think is important to capture, vs. PaaS like Heroku.
So you have a framework but it's hardcoded in the platform, right?
-
-
mostly. it doesn't have to be hardcoded tho. which is why i like thinking of it as an event-driven distributed container-spinning-up infra
-
Will it eventually just devolve to a graphQL interaction? It seems like the only way to avoid some eventual “server-less” vendor lock-in.
-
GraphQL is not magically non-proprietary ;)
-
I don’t know enough to debate graphQL encumbrances. I meant the benefit of JS asking 4 what it’s needs, unconstrained by RESTful endpoints.
-
Why are RESTful endpoints more constraining than GraphQL?
-
Every RESTful API I’ve worked with has required both client and server changes to provide additional data in one round trip. Not w/GraphQL
-
Additional data in one round trip?
End of conversation
New conversation -
-
-
The routing, or triggers that fire your functions, are configured in infrastructure templates (CloudFormation in AWS)
-
Nature of events is diverse, including HTTP. You can point all your endpoints to one function and manage routing there(Expressjs,for ex.)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.