5 ms·
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 t
by kabes 9y ago
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.
- sorenbs 9y agoHi Kabes 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-definition-language-kr84dktnp0/ 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?
- hobofan 9y agoAny 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.
- sorenbs 9y agoHi hobofan :-) 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.
- tmoorai 9y ago1) 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.
- derefr 9y agoA 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.)
- bluetwo 9y agoI would have agreed with kabes a couple years ago but I'm seeing more clients piece together services in ways I would not have expected.
- agentultra 9y agoGraphcool is a really nice service. 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. https://postgra.ph https://postgra.ph
- piaste 9y ago> 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.
- agentultra 9y ago> So... you're still locking people in 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?
- piaste 9y ago> 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.
- bm1362 9y agoIf I'm not mistaken you can host on premise?
- sorenbs 9y agoHi bm1362 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.