This is a super exciting release and I'm really excited to see the community go in this direction, specifically the ability to add more sophisticated, custom capabilities to the server. GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics.
It is also surreal to see GraphQL go from the first prototype system I wrote five years ago to where it is today. I'm so impressed with the players in the community and its humbling to see so many people take the ecosystem to new heights.
Congratulations to the whole Graphcool team on this awesome milestone!
Thank you so much for your support and most important of all, your great work on GraphQL. Without your (and others') great ideas, Graphcool (and many other tools & services) wouldn't exist today.
I've been playing with this for the last hour and I must say it is a beautifully-designed experience throughout. I've seen quite a few BaaS (Backend as a Service) products debut on HN, and I'd usually play around with them for 5 minutes and then throw them into a bookmarks folder. What really got me engaged here was the many examples, the excellent documentation, and the gorgeous interface.
You really hit that dopamine rush in a developer's mind when they imagine the possibilities. I think that was a really powerful effect that Firebase had with me and I see it here too. Really awesome platform and can't wait to see where it goes!
Thank you so much! A lot of work has gone into the onboarding experience, so it is great to see that it is working. I just gathered everybody on the team to show them your comment :-)
Hi Blackstone4 :-) I would definitely recommend you use Graphcool if you are just getting started with GraphQL. People in our slack are super friendly, so you can get help with questions around how to structure your data model, how to use the Apollo or Relay clients etc.
Hi primitivesuave! Thank you so much for your kind words!
I'm very happy you're highlighting all these points. It's indeed something we've tried to put a lot of effort into, to make the first getting started experience as nice as possible.
What I'm most excited about is the flexibility and extensibility compared to previous BaaS solutions. This is where GraphQL & serverless functions provide the perfect building blocks without resulting in vendor lock-in.
Seems well designed. But besides a startup in a rush for an MVP, who's in the market for a backend as a service?
Who wants to trust the most valuable part of their product to a third party start up that has a lot of potential to disappear from under your feat, is hard to move away from and might not be flexible enough to incorporate all your future use cases? I can't imagine selling this to any company I ever worked for.
You are raising a very valid point. You should always carefully consider pros and cons before choosing a third party provider.
The primary reason to build your product on Graphcool is speed of execution. Being able to deliver value quickly is important not just to startups, but also increasingly to enterprises getting squeezed in their core market. This is the reason companies adopt Graphcool.
We acknowledge the fear of lock-in. This is why we support open source GraphQL servers and work on standardising your project configuration as much as possible. For example, today we released the new Graphcool CLI that allows you to configure your project using the open IDL specification (https://www.graph.cool/docs/faq/graphql-idl-schema-definitio...) We also make it very easy to export all your data - either as json, using the api or as a raw sql dump.
Any plans for continous (read-only) direct database access? Without that, basically every modern BI solution can't be used. I think that besides the obvious lock-in, that's another big hinderance for building real products with Graphcool.
This is something we are planning to support. We have two approaches, and I'm curious to hear what would work best for you.
1) Add an integration for selectively syncing data to s3. This would work very similar to the Algolia integration and allow you to transform the shape of your data. Tools like Athena and QuickSight can query directly against s3 buckets, and many other services can import data from s3.
2) Add the ability to provision a read replica and offer direct read-only sql access. This option would carry a higher fixed cost, so would not be appropriate for hobby projects.
1) would a very good solution. It's adding the graph cool pieces to an existing data lake. From there anyone can do what she wants (Athena, Quicksight, Import into Redshift/BigQuery). Would love to see that.
BTW saw your talk today at AWS Summit in Berlin. Good job there.
I've had similar questions as you. When it comes to enterprise and data.. that's really the most valuable piece.
If organizations you work with are invested in PostgreSQL I'm working on a GraphQL solution similar to Graphcool with the exception that the storage layer is a plain managed PostgreSQL cluster.
> If organizations you work with are invested in PostgreSQL I'm working on a GraphQL solution similar to Graphcool with the exception that the storage layer is a plain managed PostgreSQL cluster.
So... you're still locking people in, only to your API rather than your backend?
An automatic GraphQL API generator for Postgres is a potentially awesome tool, in the same way that PostgREST is awesome. But the parent's point is exactly this: "awesome tool" (PostgREST) is awesome, "awesome tool as a service" (Graphcool, Postgraph) is dangerous.
Quite the opposite! It's no different than using Amazon RDS or PostgreSQL in Azure. All of your usual tools for managing and integrating PostgreSQL still work.
The benefit of my system is that it's an easy in to the GraphQL world. You integrate all of your data and services via boring, old PostgreSQL and it just works. My stack takes care of caching, analytics, integration, scaling, etc.
GraphQL is an emerging API specification that, I believe, will ultimately supplant REST in the long term.
> "awesome tool" (PostgREST) is awesome, "awesome tool as a service" (Graphcool, Postgraph) is dangerous.
Are you implying that on-prem software is the only way?
> Are you implying that on-prem software is the only way?
I'm stating that having the option to switch to on-prem is extremely important for your business plan. It puts a hard ceiling on how much your cloud provider can squeeze you for.
A hobbyist who isn't building a "product" at all, but rather scratching their own itch, and wants something that just "exists" on the Internet somewhere where they can forget about it (and hopefully not pay much, either.)
We offer the ability to host Graphcool in your own AWS account. This gives you complete control of your infrastructure, but also transfers the burden of maintenance and operations to you. Please get in touch if you are interested in learning more about this option.
> Basically "Serverless" in 2017 has become just a hype friendly marketing friendly way of saying "Saas".
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.
I thought it was the GraphQL equivalent of SQLite..
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.
It's kind of silly for them to compare themselves as "Serverless GraphQL Backend" vs "Backend-as-a-Service" on their homepage as if the two didn't mean exactly the same thing.
@cocktailpeanuts Graphcool is using Auth0 Extend behind the scenes (https://auth0.com/extend/developers) to handle the custom code execution. Extend is a Serverless extensibility platform i.e. there are servers but you don't have to manage them. I also agree with you that the term does get overused ;-)
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.
I think "half-assed" is rather harsh. As far as i'm concerned, GraphQL is revolutionising front-end component-based development, and solving a large number of API/platform issues.
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.
Thanks a lot for your comment! The term serverless is certainly being overused to attract attention.
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-...
I think minute incremental charges are the signature for a service that is "serverless". While serverless components are part of your architecture, what is exposed and billed monthly is a standard SaaS interface. In this sense, it is only utilized for its buzzwordiness.
I don't understand this complaint at all, these terms each highlight an interesting set of properties that seem worth having names to refer to them by.
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.
I think serverless currently means " I don't have to think about servers, provisioning or scaling". It's === to function-as-a-service. S3 is the best example so far since people see it as no servers at all, just static file serving (there USA server running S3, but as a user we don't really care)
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.
Whenever I hear serverless, I think backend as a service remarketed.
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.
When I hear "serverless" I think "no middleware, all business logic moved either to the frontend or persistance layer". Frontends are now rich UI's that can consume data directly via API from the persistance layer, and whatever transforms, queueing, etc the middleware used to do is now handled either in the UI or the persistance layer.
You'd be surprised how many people think they want "blockchain" in situations where 1 or less of those criteria are applicable. For example, multiple large corporations seem to be funding "let's make our own blockchain" projects but don't intend for anyone else to mine.
It might be a misnomer, but "severless" has been very consistent: temporary fully managed autoscaled lamdas. It's basically the app layer as a service.
We used graphcool for our latest launch and it probably saved hundreds of back end dev hours. The team is really responsive on slack and intercom, the interface is great and really robust with query permissions and flexible mutation callbacks. The pricing is more than fair.
They've been a bit slow to implement new features for production, but I understand development timelines are hard to predict.
I think the product is in a pretty good place for a limited release right now. We are really looking forward to synchronous mutation callbacks and multi-region replication (currently only eu in production, us-west-2 and asia-pac are in beta). We're using lambda functions as in-betweens while we wait on synchronous callbacks and it's been totally fine, it just breaks the "GraphQL fits all your server api needs" paradigm.
I think that the request pipeline is interesting enough to warrant a little discussion. Graphcool is running its users' code on their behalf right in the hot code path of their mutation pipeline. This means they're able to run untrusted code in an isolated and low-latency manner.
You may have seen something similar before in Auth0 Rules [1]. That the two share similarities is no coincidence! Auth0 Rules and Graphcool's 'inline functions' use the same Webtask technology behind the scenes.
At Auth0, we're working on packaging up this technology to provide an Extensibility as a Service offering called Auth0 Extend [2]. Auth0 Extend builds on the familiar webhook model but removes the friction webhooks impose on user; no more standing up and managing servers just to handle webhook invocations. Auth0 Extend makes it trivial to transform a platform's webhook integration into an in-platform custom code editing experience.
Look for more details Auth0 Extend in the coming days as we make our public launch. Also look for other exciting imminent product launches from our integration partners.
Congratulations on a beautiful and functional product launch Graphcool!
Thanks a lot - it's super inspiring to hear about all the cool projects being implemented on Graphcool!
To us it is very important that the features we implement are stable and ready for real production apps. That's why we sometime keep new features in beta for a long period while we work out all the kinks :-)
I'm looking forward to see how the new Functions will help you reduce the complexity of your app! btw - I added a link in another comment here to a post about how we see serverless functions and GraphQL play together. Would love to hear your thoughts on this.
One of the things that I think is missing from your documentation is better explanation of what happens if things fail. For example, if one of the async functions fails, do you re-run it? The async functions can have externally-visible invoking webservices and such - if something hiccups, do you run the function again? Can I come in and get a list of all the times it would have been run and re-invoke them myself later if need be?
Nobody has brought this up: why should we trust proprietary software running on the vendor's server? And more practically, how can we expect this service to be reliable in the future (related: Parse shutdown). I think this is a disturbing trend that more and more things that used to be open and on premises, are moving to the cloud/serverless/microservices hype.
When I saw mention of AWS Lambda in their docs, I thought this was going to be something I ran myself on my own AWS account. But that's not the case. I'd really like to see more BaaS run with that model. My understanding is that the AWS Marketplace API would let them charge an upsell cost, even if I'm running all the infrastructure myself; is that not the case?
That seems like the best scenario: I have access to the infrastructure if necessary, and am paying for the value add of the service over-and-above AWS (or Google/Azure). If they stop supporting it, all my instances/lambda functions/etc are still my own.
This is a very interesting model we are actively exploring. The primary issue is that the cost of the minimum infrastructure required to run Graphcool in the scalable and fault-tolerant way we have designed our architecture is too high to make it feasible for most projects.
We are offering this option on the enterprise plan, but that's a very different price point than our publicly listed plans.
Maybe it's a hybrid approach where most of the load is handled by the SaaS "mothership" but users could opt-in to running additional AWS Marketplace nodes in their own infrastructure to have more direct access to their data? This could also answer hobofan's request for a solution to BI integration.
I think that is a very valid approach. We use https://buildkite.com/ for ci and they have exactly that model, where they manage the admin panel and meta data db, but worker nodes can be deployed elsewhere
For something like this I'd have thought you'd be better off ignoring services like this and getting a Terraform setup going. Lambda functions are pretty simple to push out and it wouldn't require you to have some additional third party cruft in the middle:
I've been using Scaphold for a long time as a prototyping backend for GraphQL frontends. The biggest issue I've had with it is that its permission system always uses the most "lenient" rule, which makes multi-tenant applications impossible. Looks like Graph.cool is REALLY catching up (and their permissions system is just better).
Thanks for sticking with Scaphold. We'll be bumping up the power of permissioning soon! We've been focused on implementing more features with our schema and custom logic in the meantime :)
I'd love to have a few days of peace to be able to try GraphQL and Graphcool.
If it does the job as expected it looks super useful for small dev teams. They have solved simple auth, permissions, data modelling, cloud functions, etc.
A priori, my only complaints about Graphcool are:
- Ridiculous file storage price beyond the initial 10GB. Almost 20 times more expensive than Firebase and S3.
- No permissions for machine clients. They provide a machine key but these machines have access to the entire DB. So if you need an integration with some third party you need to spin up your own proxy.
- The UI for working on the database and models is really awesome. It would be even better with some headless CMS alternative type of UI and allow puny humans to add/edit content, files, etc. This is something most projects need anyway.
- No REST API. Yes I know, but not everyone is ready to make the jump to GraphQL and being able to implement it gradually might be a nice bonus. Or maybe you'd like to give access to a third party to some of your data. Again, this could be solved with a proxy, but it would be a nice to have.
- File storage is not where we want to earn our money. Please get in touch if you have a use case that would be prohibitively expensive with the current pricing so we can figure something out.
- More granular permissions for machine clients is something that is high on our priority. We are currently prototyping different ways to integrate it with our Permission Query system, and want to make sure we get this right before releasing.
- I think it would be awesome if someone would create an open source content editor for GraphQL apis. It wouldn't even have to be specific to Graphcool.
- Implementing a REST API is something we are considering. We see very little demand for this feature though, so not likely to happen in the near future.
> File storage is not where we want to earn our money
Why not sell storage at cost + 15% or something similar? You could also simply offer some type of GCS or S3 integration so that your users would provide their own buckets but use your fantastic API.
> I think it would be awesome if someone would create an open source content editor for GraphQL apis.
Great feedback. We have some planned integrations between file storage and the GraphQL API. We want to make sure we understand our cost structure before we commit to a price point.
What's exciting to me, having tested graph.cool and others, they are fantastic at providing an API in a format that works quite well (GraphQL) and handing the admin for me.
I don't want to build admin anymore.
Frankly, I'll spend more money at the service with the best admin UX.
It's like MixPanel for analytics. I can perform complex queries and analysis with minimal friction, which makes it worth the cost.
"Owning" isn't a selling point for me, when all of the services make it possible to dump the data.
The Andreesen Horrowitz Podcast has an interesting episode talking about this trend of specialised services removing one pain-point after the other, enabling a small company to focus on their core differentiator.
Really great to see this! We're excited to see Graphcool using Auth0 Extend for functions and this is a great use case for Serverless. When you write your function in Graphcool, GC doesn't have to provision servers to run them. All of that is handled on demand by Extend, powered by Webtask.
Thank you Glen! Auth0 Extend has really been great to work with. Such a smooth experience compared to AWS Lambda.
While we're at it I also want to plug http://sangria-graphql.org/ - the most mature GprahQL server implementation. Oleg - the maintainer - will be attending the GraphQL-Europe conference in a few days, so that's a perfect oportunity to pick his brain about all things GraphQL :-)
The Free plan is very generous and all I would need for a side-project, but can I have multiple databases on the free plan or would I need to create multiple accounts per project?
Nice to see Graphcool in HN and doing such great things in the GraphQL space. For those interested in hearing more about their back story, I did a podcast episode with their CEO on JAMstack Radio. http://www.heavybit.com/library/podcasts/jamstack-radio/ep-1...
As seasoned developer this things really make me feel old and dumb... so many acronyms, frameworks, unnecessary features, etc... that live me wondering, what kind of job requires to built things this way?
I was discussing about this with an old (60+) developer that still insists in making everything in PHP with his own CMS / framework that he built 10+ years ago.
He stated similar opinions to yours: "so many acronyms, frameworks, unnecessary features, etc". I don't know about you, but it sounded he was trying to cope with generational gap more than anything.
Nobody needs electrical powered car windows or even automatic transmission. Is it more complicated to build cars with those unnecessary features? Yes, but that's what the market expects.
Similarly, these days users expect all the bells and whistles of sophisticated user interfaces. They want to click a like button without having to refresh the whole window, and load content progressively without having to go to the next page.
For this case your analogy is way-off this topic, you focused on age/old rather than what GraphQL cool offer... The correct analogy will be something like: Why do i need to lend a machine that only builts another machine on his own premises?
We live in a world where we pay people to do things that they can do better, or faster, or things that we just don't have time to do. The reason I go to the grocery store to buy my food is because I don't have the space or time to grow the food myself.
The reason I host on AWS is because I don't have the space, power, or time to set up machines locally and scale them as needed. And I definitely don't have time to manage them. What doesn't make sense about paying for additional levels of tooling? In many cases, the economy of scale actually makes it cheaper, not just convenient.
I once watched a show about a man who was obsessed with saving money. He saw some spilled uncooked rice on the ground, and sat there picking up the individual grains for probably about 20 minutes. He was extremely self-satisfied, and thought less of people who weren't able to be so financially responsible as him, not passing up a chance to get some "free" rice. Meanwhile, the task valued his time at probably 20 cents an hour.
We spoke about this at the office just the other day. Five years ago our small team would simply not have been able to build Graphcool. By utilising the latest technologies and outsourcing as many non-core areas as possible we have come incredibly far in just 1.5 years.
This is getting a bit philosophical for me, but here's my take:
Before starting Graphcool I was the tech person on various projects and low-tech startups. For each new project I would spin up a node server + db. After 2 years I saw myself managing 10 different installations, all with slightly different configurations, different approaches to api and authorisation etc.
Had Graphcool existed back then I would have had 10 separate projects that I could switch between in a beautiful ui, all fully managed and using the same api structure. Instead I find myself today partly responsible for the 4 remaining node installations that are the teams rely on, but don't have the expertise to manage in-house.
It makes perfect sense if you consider that the reason stuff like Graphcool and GraphQL exist is because the need of decoupling the front end stack. And the need to decouple it is because it's becoming increasingly complex.
> Why do i need to lend a machine that only builts another machine on his own premises?
You could just spend money/time to build the machine yourself. Right?
You are not understanding the problem and therefore you are shifting the POV from an IT problem to an economic problem. M going to use a more direct "example" from my POV: Imagine if JetBrains suddenly forces you to use their own "cloud platform" to host your own applications and projects? of course the IDE it's free and you can prototype everything for free, just need to paid for what you use, they got your back as longest you paid them to.
Sorry about the delay here, it was a busy night for us.
The enterprise page is targeted decision makers in big companies who might have been sent there by the dev team. As such our main objective is to communicate that GraphQL is a proven technology.
We will make that more explicit on the page. Some of these companies actually do use Graphcool for small projects and prototyping, but that is not the story we want to tell on this page.
As a decision maker, this kind of dishonesty will ensure I can't do business with you. It's a customer list and nowhere does it state that they just use GraphQL and are not your direct customers. I know you're trying to get some traction and all that, but this makes your whole offering look dodgy
Agree, I understand you need to have referenceable customers...but you have to actually...like...have them. I would imagine you are violating restrictions around the use of these companies trademarks.
Similarly confused by the random logos on the homepage with no context. The implication is they somehow rely on Graphcool.
Really excited about this launch, Graphcool has been an awesome part of the GraphQL community, organizing the upcoming GraphQL Europe conference, and creating some great content. I work on Apollo, a set of tools for GraphQL including some client libraries, and if you're looking to get started building a full-stack app with GraphQL, Graphcool, and Apollo, there are some really great options!
I'm building a little react-apollo web app with a graphcool backend, and the backend part is just so dead simple. I don't have a lot of time to work on this app (full time dev with three kids) so the time savings on not needing to worry about the backend is a huge help. I can just focus on the front end.
(Hope I can get the free lifetime project tier too!)
One issue I had with Graphcool in the past is the high latency. I'm in the mid-west of North America and a request would typically take far longer than I would expect. I'm wondering where the servers are actually located?
We are aware of higher than expected latency from certain regions. We are working to mitigate this and in addition we will announce two additional regions in the near future to compliment our current EU region.
The major gripe I have with BaaS platforms like Graphcool or Firebase, is that they offer basically no protection against third parties stealing my public data straight from my API.
With my own backend, at least I can throttle or ban clients that are incurring in abusive behaviour. Same goes for rendered HTML – to avoid scraping.
Is there anything in the Graphcool roadmap regarding this?
Q for sorenbs or schickling or anybody else on the team: how far can you take it in terms of disk IO (not the serverless API portion) scaling? If I build a consumer web product on graph.cool and blow up, what's the end of the runway?
We can help you go very far as long as you are able to pay for the underlying infrastructure. You can start out on of our normal plans, and transition to a dedicated installation when you need to.
We run customer databases on AWS Aurora and can scale up to 15 low-lag read replicas.
Feel free to send me a message at soren@graph.cool if you want to talk more about this. Also happy to jump on a skype call if that's more convenient for you
It's always good to see more companies push for GraphQL.
There are a few others like this, one of which I co-founded, called Scaphold.io (https://scaphold.io), and we're huge proponents of GraphQL and Serverless as well. It truly is the future of app development.
If you're interested in learning more about using Serverless with GraphQL, feel free to join the Serverless GraphQL Meetup that we're hosting (https://www.meetup.com/serverless-graphql).
I'm really looking forward to see where the new RFC process will take GraphQL in the next few years. Was great being able to contribute to the standardisation process for subscriptions.
Hi there! I assume you mean something equivalent to GROUP BY or MAX in SQL? This is one of the highest requested features on our roadmap. You can see a proposed syntax for this at https://github.com/graphcool/feature-requests/issues/70
I would love to hear from other developers who have used both GraphQL and Firebase to see if there is any way we can make GraphQL an even better choice.
Nice. It would be cool to see a "kitchen sink" example project, similar to Firebase's Friendlypix, or something similar. Give people something to explore and hack on. I saw many good example projects, but nothing as full-featured.
IMO the biggest problem with Firebase is data modelling and querying. No relationships, very basic filtering capabilities, etc. That should be a deal breaker for any serious project.
I wrote this a couple of months back where I expand on that and other pain points:
Hi Krashidov! https://stackshare.io/graphcool is a good neutral way to compare Graphcool and Scaphold. I'd recommend that you spend a few hours with both services before deciding which one to go with.
But .... this had 4 points when I first spotted it on the front page of HN. I've seen many things get more points and never make it to front page. Does HN mimic Product Hunt now in that there are super users who can push content to front page, or has it always been like that?
You can't compare points over time between stories directly because of the anti-abuse software. This story made it to the front page by user upvotes, nothing fancy.
It is also surreal to see GraphQL go from the first prototype system I wrote five years ago to where it is today. I'm so impressed with the players in the community and its humbling to see so many people take the ecosystem to new heights.
Congratulations to the whole Graphcool team on this awesome milestone!