Graphcool – Serverless GraphQL Back End
graph.cool
graph.cool
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!
We've written up a blog post about how we think an architecture combining GraphQL and serverless functions could look like on the backend: https://www.graph.cool/docs/blog/introducing-the-serverless-...
P.S. we're also currently on Product Hunt and appreciate any kind of support :)
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!
I was thinking of using React.js + Graph.cool with a Node.js server to handle subscriptions and background tasks/calculations
You should consider following one of our tutorials to get a jumpstart into GraphQL: https://www.graph.cool/freecom/
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.
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.
Does that answer your question?
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.
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.
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?
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.
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".
That said, I think the platform looks great!
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.
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'.
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.
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.
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...
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.
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.
Edit: it looks like today they just released "request pipeline" which is actually a pretty robust synchronous callback. Impressed at the thought that went into this. -- https://www.graph.cool/blog/2017-05-16-introducing-a-cli-fun...
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.
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!
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.
edit: typo
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.
https://www.terraform.io/docs/providers/aws/r/lambda_functio...
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.
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.
Hmmmmm (wheels turning)
Forcing me to request an invite or register to know more about a product is the fastest way of making me close the browser tab.
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.
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 :-)
P.S. Your onboarding is amazing walking me through setting up the first schema, I hope https://www.useronboard.com/onboarding-teardowns/ does a teardown of it someday.
You can create as many projects on the free plan as you like, all under the same account.
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.
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.
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.
> 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?
> they got your back as longest you paid them to
Yeah, vendor lock-in is a problem, but depending on the size of your operation it might make sense.
With GraphQL based solutions it's less of a problem though.
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.
Similarly confused by the random logos on the homepage with no context. The implication is they somehow rely on Graphcool.
1. Learn Apollo, build a simple Pokedex app: https://www.learnapollo.com/
2. Freecom, an intercom clone: https://www.graph.cool/freecom/
Getting started only takes a few minutes, and you can get a taste of the awesome experience you can get as a frontend developer building on GraphQL.
The sale of early bird tickets ended a few days ago, but I just created a special 30% discount code for hn: https://www.eventbrite.de/e/graphql-europe-tickets-326484042...
If you are in Europe, I'd encourage you to check it out. There are some really interesting talks lined up. And Berlin is an awesome city :-D
The full schedule is available at https://graphql-europe.org/
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.
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?
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
> To celebrate being hunted on Product Hunt, every product hunter gets a free lifetime project plan!
How do you get that? I signed up, but it only gave me the basic one free.
We will activate the lifetime project plan for everybody tomorrow. Feel free to explore the product in the meantime!
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.
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.
I wrote this a couple of months back where I expand on that and other pain points:
https://medium.freecodecamp.com/firebase-the-great-the-meh-a...
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?
https://medium.com/@benjiwheeler/how-product-hunt-really-wor...