Prisma – An open-source GraphQL API layer for your database
blog.graph.cool
blog.graph.cool
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!
Let me try to clear things up :-)
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.
Which includes integrating it into their BaaS/PaaS platform, I imagine.
@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 :-)
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/
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.
https://github.com/begriffs/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 is a pretty cool project that was on hn yesterday actually https://news.ycombinator.com/item?id=16150663
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.
If you haven't checked it out yet, then I'd encourage you to take a look at GraphQL bindings and how that allows you to work with your own server for more complex scenarios: https://blog.graph.cool/reusing-composing-graphql-apis-with-...
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.
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.
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!
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?
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 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.
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'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 :-)
See my comment higher up about the main difference :-)