4 ms·

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

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/ https://www.graphile.org/

lastmjs 9y ago
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.
eloff 9y ago
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.
sorenbs 9y ago
Thanks everdev! Postgraphile is a pretty cool project that was on hn yesterday actually https://news.ycombinator.com/item?id=16150663 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-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...
bringtheaction 9y ago
Ha ha I love when I get excited about something "new" only to find that I've already starred it on GitHub. I might have a "star and forget" problem...
walshemj 9y ago
should not your business login be in the database where it will runfaster as SPROCS
- ruslan_talpa 9y ago
  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.
  - TomMarius 9y ago
    They often mean "badly written logic in badly configured MySQL". Logic in DB(2) literally powers our world.
cpursley 9y ago
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 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 https://github.com/subzerocloud/subzero-starter-kit
- cpursley 9y ago
  https://github.com/subzerocloud/postgrest-starter-kit/wiki/Beyond-Data-Access#when-all-else-fails-take-full-control https://github.com/subzerocloud/postgrest-starter-kit/wiki/B...
ruslan_talpa 9y ago
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 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.
rozenmd 9y ago
What's so difficult about just writing resolvers?
- sorenbs 9y ago
  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.

lastmjs 9y ago

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.

eloff 9y ago

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.

sorenbs 9y ago

Thanks everdev! Postgraphile is a pretty cool project that was on hn yesterday actually https://news.ycombinator.com/item?id=16150663 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-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...

bringtheaction 9y ago

Ha ha I love when I get excited about something "new" only to find that I've already starred it on GitHub. I might have a "star and forget" problem...

walshemj 9y ago

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

ruslan_talpa 9y ago
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.
- TomMarius 9y ago
  They often mean "badly written logic in badly configured MySQL". Logic in DB(2) literally powers our world.

cpursley 9y ago

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 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 https://github.com/subzerocloud/subzero-starter-kit

cpursley 9y ago
https://github.com/subzerocloud/postgrest-starter-kit/wiki/Beyond-Data-Access#when-all-else-fails-take-full-control https://github.com/subzerocloud/postgrest-starter-kit/wiki/B...

ruslan_talpa 9y ago

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 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.

rozenmd 9y ago

What's so difficult about just writing resolvers?

sorenbs 9y ago
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.