Prisma – Database tools for modern application development • Hacker News Board

Re: Prisma – Database tools for modern application development

#81

Post by BenjieGillam » Mon, Apr 08, 2019, 10:09 AM UTC

nikolasburk wrote: post #73

Illniyar wrote: post #71

Earlier quoted context omitted.

This is really not clear from the site. Even after I skimmed the tutorials and docs. I would imagine it should be front and center like in Hasura and Postgraphile . I would be tiffed if I found out after I started developing with it using the cli that I need to setup another server and process in my production environment.

(I work at Prisma) It is very important to understand that Prisma is NOT a GraphQL-as-a-Service like Hasura or Postgraphile. It's really a suite of database tools that you can use for any use case (building GraphQL, REST or gRPC APIs, or use it in any other app where you need a database). We recently wrote a blog post about this topic: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/ Also, the Prisma serve…

It feels a bit misleading to say PostGraphile is "GraphQL-as-a-Service". Typically XaaS is used when there's an external service (normally hosted elsewhere) that provides this functionality; whereas PostGraphile is 100% self-hosted, we do not even have a hosted offering. Further, PostGraphile is more of a framework for building a GraphQL API than a separate service you run - since it's pure JS (well, TypeScript) a decent portion of our users mount PostGraphile directly into their Express or Koa applications and deeply integrate it, including customising and extending it via plugins. It's much more of a library/framework than an "-as-a-service". (I'm the PostGraphile maintainer.)

Re: Prisma – Database tools for modern application development

#82

Post by [deleted] » Mon, Apr 08, 2019, 10:43 AM UTC

rishav_sharan wrote: post #57

hn_reddit_human wrote: post #54

Hm... is this is like JOOQ[1] for non-Java languages? Or maybe more like a typed version of massivejs[2]? [1] https://www.jooq.org/ [2] https://massivejs.org/

Sorry for being out of context, but why is your name in green? This is the first time I have seen a green name in HN.

[deleted]

Re: Prisma – Database tools for modern application development

#83

Post by jacques_chester » Mon, Apr 08, 2019, 11:31 AM UTC

Aeolun wrote: post #55

jacques_chester wrote: post #45

Earlier quoted context omitted.

> SQL results, coming without any translation layer, are untyped. That would depend on the database's wire protocol, wouldn't it?

Do I really have to qualify this with ‘mainstream databases, with mainstream client libraries, in nearly all major languages’?

I don't know. That's why I asked. I did a quick lookup of libpq and it gave the impression that it can answer for column types.

Re: Prisma – Database tools for modern application development

#84

Post by mavilein » Mon, Apr 08, 2019, 11:39 AM UTC

turboturbo wrote: post #29

I’ve tried Prisma over the last few months, but eventually decided against adopting it in our product because it seems very inflexible when working with many-to-many relationships. In particular, filtering on foreign keys doesn’t seem possible and requires SQL table joins, which (in our case) has an immensely negative performance impact. Also, the query chaining API doesn’t lend itself well to filtering on multiple r…

Thanks for that honest feedback! That was indeed a drawback we had and we often had this point coming up in customer conversations. This is why we started an effort to lift this limitation a few months ago. The result of this work is a new Datamodel specification that allows you to take full control of how relations are implemented. You can check it out here: [GitHub - prisma/datamodel-v1.1-feedback](https://github.com/prisma/datamodel-v1.1-feedback) Your use case description sounds like you want to take really control of a lot of details here. Therefore I would suggest you to introduce a model that is backed by your relation table. Then you can freely filter on this model and then traverse relationships from there. If you want to chat more about how to implement in detail feel free to reach out on our public Slack (my nick there is: marcus).

Re: Prisma – Database tools for modern application development

#85

Post by kilburn » Mon, Apr 08, 2019, 2:18 PM UTC

Aeolun wrote: post #38

turboturbo wrote: post #29

I’ve tried Prisma over the last few months, but eventually decided against adopting it in our product because it seems very inflexible when working with many-to-many relationships. In particular, filtering on foreign keys doesn’t seem possible and requires SQL table joins, which (in our case) has an immensely negative performance impact. Also, the query chaining API doesn’t lend itself well to filtering on multiple r…

Forgive me if I’m missing something here, but joins seem pretty much the only way to do performant foreign key filtering to me. Is this not what you were talking about?

It wasn't my question, but I would assume the caveat they were complaining about is that prisma forced them to perform the join when filtering the original table by just the foreign key (think select * from books where author_id = ? ... no join to aauthors needed here, but some ORMs do that join anyways)

Re: Prisma – Database tools for modern application development

#86

Post by tathougies » Mon, Apr 08, 2019, 4:37 PM UTC

Aeolun wrote: post #55

jacques_chester wrote: post #45

Earlier quoted context omitted.

> SQL results, coming without any translation layer, are untyped. That would depend on the database's wire protocol, wouldn't it?

Do I really have to qualify this with ‘mainstream databases, with mainstream client libraries, in nearly all major languages’?

Mainstream databases like Postgres and SQL server (and MySQL too I think) all return type information with their results. Having written wire protocol clients for these, I flat out reject your claim that SQL isn't typed at the results level. It's one of the few places in common usage that the types are explicitly stated. Whether or not your client libraries reflect that is a different issue (and if they don't, I encourage you to use something better).

Re: Prisma – Database tools for modern application development

#87

Post by querulous » Mon, Apr 08, 2019, 5:30 PM UTC

mavilein wrote: post #64

hn_reddit_human wrote: post #54

Hm... is this is like JOOQ[1] for non-Java languages? Or maybe more like a typed version of massivejs[2]? [1] https://www.jooq.org/ [2] https://massivejs.org/

No Prisma is not like JOOQ. We are happily using JOOQ internally at Prisma so i happen to know. The main differences in my opinion are: - JOOQ is a SQL Query Builder which is typesafe in regards to the fact that you cannot make SQL syntax errors in your query. However you can still write queries that are e.g. using a table that does not exist. In contrast the Prisma Client gets generated for all your tables and colum…

jooq can also introspect your database and ensure you only use existing tables and columns and your data types are in agreement

it however requires you do this at compile time, not runtime. does prisma do the introspection at runtime?

Re: Prisma – Database tools for modern application development

#88

Post by joshstrange » Mon, Apr 08, 2019, 6:38 PM UTC

nikolasburk wrote: post #75

viksit wrote: post #27

Earlier quoted context omitted.

Ah so this is similar to Hasura.

I work at Prisma, we've recently written a blog post about exactly this question where we also compare Prisma to other services like Hasura or AWS AppSync: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/

Relevant parts:

> Comparing Prisma to AWS AppSync & Hasura

> With the new understanding of the role of Prisma's CRUD GraphQL API, it becomes clear that Prisma is not in the category of "GraphQL-as-a-Service" anymore.

> Tools like AWS AppSync and Hasura provision a generated GraphQL API for your database (or in the case of AppSync also other data sources). In contrast, Prisma enables simplified and type-safe database access in various languages.