Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prisma – An open-source GraphQL API layer for your database

blog.graph.cool

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Prisma – An open-source GraphQL API layer for your database

#11

Post by sorenbs »

mrbarletta wrote: post #9

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 underst…

Thanks mrbarletta!

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.

Re: Prisma – An open-source GraphQL API layer for your database

#12

Post by LawJolla »

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?

Re: Prisma – An open-source GraphQL API layer for your database

#13

Post by LawJolla »

mrbarletta wrote: post #9

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 underst…

I'm also interested in #1!

Re: Prisma – An open-source GraphQL API layer for your database

#14

Post by cpursley »

everdev wrote: post #2

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: http…

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:

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:

https://github.com/subzerocloud/subzero-starter-kit

Re: Prisma – An open-source GraphQL API layer for your database

#15

Post by johannpinson »

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)

Re: Prisma – An open-source GraphQL API layer for your database

#16

Post by cpursley »

cpursley wrote: post #14
everdev wrote: post #2

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: http…

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: 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: https://github.com/subzerocloud/…

https://github.com/subzerocloud/postgrest-starter-kit/wiki/B...

Re: Prisma – An open-source GraphQL API layer for your database

#18

Post by ruslan_talpa »

everdev wrote: post #2

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: http…

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.

Re: Prisma – An open-source GraphQL API layer for your database

#19

Post by ruslan_talpa »

walshemj wrote: post #10
everdev wrote: post #2

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: http…

should not your business login be in the database where it will runfaster as SPROCS

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.

Re: Prisma – An open-source GraphQL API layer for your database

#20

Post by rozenmd »

everdev wrote: post #2

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: http…

What's so difficult about just writing resolvers?
Post reply on HN