3 ms·
So this pattern forces specific technology choices on you (GraphQL), and encourages vendor lock-in by going all-in on "Serverless" cloud functions. No thanks.
by vlucas 8y ago
So this pattern forces specific technology choices on you (GraphQL), and encourages vendor lock-in by going all-in on "Serverless" cloud functions. No thanks.
- tango12 8y agoWell, you could also “serverless” with kubernetes and vendor + OSS ecosystem around running containers with 0-n scaling aka serverless is also getting better. Also, GraphQL is important because it’s a convenient way for clients to consume asynchronous information.
- ericfrederich 8y agoOpenFaaS
- rjbwork 8y agoWe do our "serverless" using the self-hosted version of Azure Functions - Azure Webjobs. For most of the events we can scale out to 32 beefy machines. We also don't use graph SQL, preferring simple rest endpoints made in Web Api 2, and some reporting functions. If we need to do more than that...well, we'll have to rethink some things. It will be a good problem to have.
- diddid 8y agoWhile I agree Azure web jobs are awesome, I’m not sure I would call them serverless. They require you to provision an app service and would only scale within whatever tier you have and ultimately share resources with any sites you have on the same sever. Microsoft actually has an on-prem or self-hosted version of Azure functions that uses docker, though it’s still only in preview.
- z3t4 8y agoAfter websockets got available in all major browsers I make almost all apps this way, but I use plain JSON instead of GraphQL. A request can look like this: {person: {name: "Jon"}}.
- winrid 8y agoThe way they pitch it, yes. In reality you could use any data store and any backend language/whatever and you would get the same affect. What they're pitching isn't really revolutionary - it's basically putting a queue between your mouse and state management/business logic.