yes! exactly. we don't have a web framework here; it's present in the uhhh serverless framework/platform/whatever you wanna call it
-
-
So you have a framework but it's hardcoded in the platform, right?
2 replies 0 retweets 0 likes -
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
1 reply 0 retweets 0 likes -
Will it eventually just devolve to a graphQL interaction? It seems like the only way to avoid some eventual “server-less” vendor lock-in.
1 reply 0 retweets 0 likes -
GraphQL is not magically non-proprietary ;)
1 reply 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
Why are RESTful endpoints more constraining than GraphQL?
1 reply 0 retweets 0 likes -
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
2 replies 0 retweets 0 likes -
For the standard blog post and comments example, you may initially just show blog title. Later, you add # comments. Later show snippets.
1 reply 0 retweets 0 likes -
For each change, of course the JS must change and it somehow asks a server for the data. A GraphQL server already knows how to respond.
1 reply 0 retweets 0 likes
JSON:API has that same characteristic, and is a REST API. http://jsonapi.org/format/#fetching-includes …
-
-
Ok. They do seem to have feature parity here. My main point was that if your server can handle one of them then you have 1 endpoint.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.