The 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.

We 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.

Well, 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.

After 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"}}.