I've been using graphcool (0.1) for quite some time, on a paid plan.
I feel so lost with so many changes lately, graphcool 1.0, now prisma, first it was a baas, then open sourced, then only a graphql database, etc.
My question are
(and I totally thank you guys for the great tool you created)
#1 how will you profit from it?
I need to make sure we invest in a tool that will be supported.
#2, how do I migrate? I understand that now I have to take care of a lot more than before, but the information available ain't clear, instead of saying "Hey, we no longer will create everything for you, make sure you learn how to tie graphql-yoga + bindings+ prisma" you were saying "We will focus on graphql database" which led us wonder what it meant.
I think your decision to focus on the hard problem is the right one, it just that our relation as users/customers of graphcool has changed and that wasn't very well explained.
The Graphcool Framework is a all-in-one framework that combines a GraphQL query engine (now called Prisma), serverless functions and managed hosting (Graphcool Cloud).
Prisma is a major rewrite of the query engine. You can think of Prisma as the query engine powering the Graphcool Framework.
Today Prisma can be used stand alone as a GraphQL database layer in combination with GraphQL Binding. Later we will change the Graphcool Framework to use Prisma as the query engine.
In short - if you like the features of Graphcool Framework, you can keep using it like nothing changed.
@hobofan Prisma will find its way into our Cloud offering over time. I can't commit to a timeline yet
@LawJolla et al - We have seen tremendous growth in our Cloud business since the launch. Watch out for announcements in this space over the coming months :-)
These DB -> API tools show promise, until you want to do something outside the CRUD box like upload images or process payments.
Also, I've found it much harder to modify functionality because now your business logic is embedded in your DB which is harder to version than backend code.
In any event, if you want a GraphQL/DB API and don't want to pay for graph.cool, there's a great similar tool called PostGraphile: https://www.graphile.org/
When you say "logic" in your database, that usually means views/triggers/functions. I don't see why you can not version them, keep them in git and treat as any other code. Yes there are edge cases where there are some interdependencies, or that it's harder to "replace" functions when the signature changes, but if you are just a bit careful, and try to keep your views/functions (logic) a bit separate from tables (state), then in most cases you can just replace them, sort fo like copying a new version of a file.
I would say that the tooling is lacking in this area but there is no big underlying obstacle that would prevent you from working with code in the database the same as with code in other envs. For PostgreSQL in particular, a combination of Sqitch and Apgdiff works quite nicely. I've combined them for a particular project structure (https://github.com/subzerocloud/subzero-cli) but this approach can be generalised. I have all my database code (including table definitions) in separate files/folders, split however i want (modules), work on them in any oder i need, when the time comes to deploy, apgdiff does the diffing between live and dev versions of the database, creates the new migrations DDLs automatically, and than those migration files are managed by sqitch and deployed.
If you want an automatic REST API, but on top of PostgreSQL and Haskell (you don't have to touch Haskell, but benefit from its type safety and performance), check out PostgREST:
If you need GraphQL and standard PostgREST endpoints (as well as a few other tools like Openresty), this starter kit is really nice and fires right up with docker-compose:
PostGraphile and Prisma takes different approaches in that PostGraphile embraces the power of PostgreSQL and encourages you to place business logic in the database.
Prisma on the other hand is a separate piece of infrastructure that you deploy in front of a database to add extra functionality such as realtime subscriptions, rate limiting etc.
I think the point of this release is to open up operations outside of CRUD. I'm not sure if you've been following graph.cool, but they've been having a lot of churn over the past few months. The issue you bring up about CRUD has been addressed and is one of the main reasons for this new release, as far as I understand.
How does Prisma cause your backend logic to move into the database? I don't believe you need to add stored procedures to use it, you just write GraphQL resolvers for nodejs as per usual.
Implementing a single resolver is not difficult. The trouble starts when you need your server to operate fast and efficiently on a broad range of query patterns.
The switch from REST to GraphQL moves the burden of data fetching from client to server. As GraphQL is dynamic in nature you have to handle any query the frontend might send and can no longer rely on the static shape of a REST API when optimising your data access pattern.
The fundamental issue is that there is a big gap between the GraphQL API you want to expose and the underlying data layer you have available. Sometimes you need to combine data from several underlying databases making it critically important to perform data queries in the right order and in parallel when possible.
Think of Prisma as a GraphQL database query engine that analyses every incoming query in order to generate an optimal execution plan for your underlying databases.
Usually people say the opposite, logic in db does not scale, though i don't know what scale are they talking about when modern databases (PostgreSQL/MySQL), on a single decent box can handle 1M+ TPS (and that is before using replicas to scale reads).
As to your comment, nothing is black and white, but if the logic operates strictly on the data (not interfacing with 3rd party systems), having it in the db imo is better/less complex.
Graphcool is awesome. I think you guys made the right choice moving to a code-first, open-source platform.
Obviously you still need to make money. Besides hosting and automatic backups, how will you monetize? What are your plans for Graphcool Enterprise on-premise?
It was awesome to see how Graphcool enabled so many frontend developers to get started with backend development.
And it has been even more exciting to see these same developers move to a combination of Prisma and GraphQL bindings with relative ease.
The GraphQL ecosystem is maturing to a point where the tools are now easy enough to be used by small dev shops and powerful enough to be used by large enterprises. There was an episode on GraphQL Radio (https://graphqlradio.com/) diving into how IBM build their own library to standardise schema composition. This is a fairly advanced concept, but with GraphQL binding this is now part of day-to-day development for thousands of developers.
To address the money part - Enterprise and on-premise is certainly a thing. We get a lot of requests for custom setups. If you are interested to explore this option, please get in touch!
Huge fan and user of Graphcool the BaaS! My question concerns permissions.
I thought Graphcool did a phenomenal job of permission/authorization. The tutorials seem to kick authentication to the application layer. That seems appropriate.
I think one of GraphQL's pain points is lack of a permissions pattern. It's typically hand rolled at the field / resolver level, leaving a lot of messy code. Will permissions be a part of Prisma and, if so, is there a road map for how granular they can be?
Thank you so much for putting your trust in Graphcool!
The Graphcool Permission system is super interesting because it ads a surprising amount of expressive power to a declarative permission system. We actually brought over the idea to prisma-binding https://www.npmjs.com/package/prisma-binding by including the `exists` query. For now you have to manually perform the check in resolvers, so it is not a complete substitute.
Speaking of permissions in Prisma in general. For now it includes a fairly primitive token based system: You either have full access or no access at all. In the future we will add more fine-grained grants so you can give some users read access to specific types while preventing data mutations for example. The details are still being worked out, and this system will not be as flexible as Permission Queries in Graphcool Framework.
I tried to use graph.cool as my first graphql project, everything was a breeze, except:
* I couldn't for the life of me find out how to implement user auth.
* The json fields are sooo small, it's a huge no-go for developers (like me) who are used to postgres's amazing json support.
I ended up just using neelance's Go lib and postgres.
Thanks! Your experience match the feedback we are getting from a lot of people.
With Prisma we are focusing on the core technology and exposing as much raw database power as possible. We will implement native PostgreSQL support in the future to take advantage of the superior json handling
I tried to deploy this the other day and got stuck waiting in it's wizard to create a bunch of docker containers. (which I waited 30 minutes then gave up)
I'd like it more if it was just a standalone server and not a bunch of "magic" scripts to standup/deploy.
I'm sorry you got stuck setting up docker on your local machine. We have put a lot of work into making sure local clusters "just work". It would be a big help if you could start a thread on the forum so we can help identify the issue.
The reason we are using docker to run Prisma locally is that we believe it is super important to have the same environment locally when you develop as when you run in production.
If you are familiar with docker you can follow the guide in the docs to set it all up without relying on the CLI. That should give you a little more transparency into what is going on :-)
How looks great!
After looking about the BaaS, Framework, and now Prisma, I don’t really have a question about the relation between them.
I feel that it just a “wrapper” or something else, because it combine with the binding and yoga package, so it’s not really clear what is the role played by Prisma inside this ecosystem?
(but soon i will look at it very closely)
My question are (and I totally thank you guys for the great tool you created)
#1 how will you profit from it? I need to make sure we invest in a tool that will be supported.
#2, how do I migrate? I understand that now I have to take care of a lot more than before, but the information available ain't clear, instead of saying "Hey, we no longer will create everything for you, make sure you learn how to tie graphql-yoga + bindings+ prisma" you were saying "We will focus on graphql database" which led us wonder what it meant.
I think your decision to focus on the hard problem is the right one, it just that our relation as users/customers of graphcool has changed and that wasn't very well explained.
keep the great work!