Basically "Serverless" in 2017 has become just a hype friendly marketing friendly way of saying "Saas".
That said, I think the platform looks great!
Agreed. I was momentarily very confused when I clicked on the link thinking that this was some sort of pure client-side GraphQL library that was supposed to replace functions normally done on the server.
Please don't call yourself "Serverless" if your service goes down with the remainder of the world once AWS has some problem. Please don't call yourself "Serverless" if someone acquihiring you means my database disappearing from under me.
:-D
Based on the title, I also was expecting something that was designed to run client-side.
It clearly doesn't mean 'no servers involved'.
https://code.facebook.com/posts/1691455094417024/graphql-a-d...
It would appear it's a half-assed string-based, semi-structured ddl / query-language aiming to be a middleware between actual data storage and thin clients, presenting legacy data as a graph (rather than, say, a (filesystem-like) tree or a relational table structure). Surprisingly the responses are json while the queries, as far as I can tell, cannot be parsed as js/json - but look very similar.
Based on that, I gather this is firebase with a graphql front-end: a db-as-a-service with no clear path to move off of if needed? (compared to, say, sql-server as a service).
Perhaps harsh, but at least put like that I think both the value-proposition and trade-off is more obvious?
Assuming I understood it correctly, of course. Corrections welcome.
It's not an exaggeration to say that rarely a day goes by when I don't overhear a conversation describing a problem that simply wouldn't exist if they were using GraphQL. It's not a new idea, there's a lot of prior art, but GraphQL is starting to gain serious traction - with a lot of big name adopters.
You're right in that Graphcool is essentially a GraphQL-server-as-a-service, personally I don't have any use for it, but i'm glad it exists.
I do think though, that there is value in talking about new kinds of software architecture is enabled by serverless infrastructure. I wrote up a post on how we at Graphcool use serverless functions internally and what we are planning to integrate in the platform in the future: https://www.graph.cool/docs/blog/introducing-the-serverless-...
That nitpick aside, this looks pretty neat.
AI is usually an algorithm that is generalizing patterns from data, IoT means low-powered, cheap devices that are internet enabled (which obviously have very different properties than, say, a desktop computer).
Serverless also seems to have a pretty concrete definition of being built on top of AWS Lambda (or possibly a hosted Kubernetes-like system fits the bill as well) where the server/VM/OS is completely abstracted from you. This leads to completely different systems than, say, a LAMP stack where you're managing a Linux OS and the single-point-of-failure issues that come with it or a SAAS service where none of the code running is your own. I guess it's most similar to some "PAAS" systems (like Heroku or Firebase), but from what I've seen serverless seems to focus on being composable, small/simple independent building blocks whereas a lot of PAAS services that I've seen are a single framework where you're often running something like a monolithic rails app. Serverless kind of feels to me like PAAS meets microservices. It's nice to have a name to refer to this idea.
Of course lots of things won't fall exactly into one of these buckets as technology continues to evolve, and other things will try to use these names when maybe they arguably shouldn't qualify. But that hardly makes the categories themselves meaningless.
With traditional infrastructure you have to think about capacity in discrete units of hardware. Should I provision one or two servers? Even if you can start and stop servers with an api call, you always have to keep these servers running, because rampup time is in the order of minutes.
At Graphcool we have thousands of serverless functions. Most of the time they are not running, but they are all ready-to-go wit delay measured in milliseconds, and they scale individually unbounded of the number of servers you have provisioned up front.
It's quite remarkable to think about the flexibility this characteristic afford you when architecting your applications.
A few years ago they were tried and never fully caught on largely because people saw the inherent vulnerability of betting your entire backend on a company you don't control.
It has that old problem of being beholden to a single vendor.
Our view is that the main reason Parse and Firebase didn't manage to gain mainstream adoption is that they were too limited. At the time, limitations imposed by available infrastructure forced them to to adopt a nosql model that made it very hard to implement advanced business logic. We have come a long way since then, but unfortunately Firebase is still stuck with the same fundamental data structure.
Here are some good resources on this topic:
https://www.graph.cool/docs/tutorials/graphql-vs-firebase-ch... https://medium.freecodecamp.com/firebase-the-great-the-meh-a...