5 ms·

While the implementation certainly seems very nice, the ideas behind Prism 2 aren't particularly new, or unique for that matter. For example the .NET ecosystem

While the implementation certainly seems very nice, the ideas behind Prism 2 aren't particularly new, or unique for that matter. For example the .NET ecosystem already has (for a long time) most of the stuff that is presented as being uniquely offered by Prism: generated database clients (LINQ-to-SQL, Entity Framework), generated data models (EF POCO's), type-safe queries (LINQ) etc.

sorenbs 6y ago
This is why we are focusing on the Node and Go ecosystems first :-) If you liked the developer experience in the .NET ecosystem but find yourself needing to work with JavaScript or Go, you'll probably like Prisma.
abraxas 6y ago
Everything is being reinvented from scratch in the JS world. The insistence on unifying into one language means that a lot of tried tested and true has been tossed aside and it's all being rebuilt sometimes with dubious benefit.
- hypewatch 6y ago
  And perhaps detriment. Nodejs apps are notoriously more difficult to keep secure because of how many npm dependencies are needed for a project and how often vulnerabilities are discovered in those dependencies.
- RedShift1 6y ago
  And at the end of the day all we do is select, insert, update and delete in some database.
  - kevas 6y ago
    True true
- pmart123 6y ago
  Same thing happened with Python for data science in 2023-2015. ie reinvent SQL using Python DSL.
  - yagodragon 6y ago
    Have you tried jupyter notebook + pandas dataframes? You just import a csv and you can explore, clean, manipulate data and make any sort of calculation using a real programming language. On top of that you can use something like seaborn and create visualizations. Then you click print pdf and you're ready. It almost feels like cheating. You can say all you want about how fast,optimized and superior SQL is, but the python experience is way better for almost any time you need to make sense of some data.
    - disgruntledphd2 6y ago
      Not the OP, but I have. I've spent years doing the work that you specify above, and pandas & notebooks are probably one of the least good tools for it. SQL is super fast and useful (and everyone understands it, at least in the data world), while dplyr and ggplot2 are basically a DSL for this work, while pandas is an irritatingly bad clone of base-R which manages to keep the bad parts of both Python and R, while having the good parts of neither. I really feel like you should try Rmd with R if you like the notebook flow, as it's similar but much much better. If you really want to stick with Python, then org-mode is a much better notebook than anything else.
    - pmart123 6y ago
      I have a significant amount of experience with both of them. For pandas, it is fine for initial exploratory analysis (input, plot, reshape and export, etc). However, it's API has inconsistencies and subtle "features" around silent data coercion that make it hard to use in production. Seaborn is much nicer to work with than matplotlib and Jupyter is useful for making interactive presentations. So I believe Pandas/Jupyter have a place, but then there was a tendency to create a Pandas-like wrapper for all data retrieval such as: https://github.com/ibis-project/ibis https://github.com/ibis-project/ibis https://github.com/blaze/blaze https://github.com/blaze/blaze
nikolasburk 6y ago
Some of the ideas we've built into Prisma are certainly inspired by tools in other languages and we've looked a lot at LINQ and the C# ecosystem in general as we designed Prisma! However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se! For example, we're already working on Prisma Client for Golang which is already available in alpha! [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://github.com/prisma/prisma-client-go https://github.com/prisma/prisma-client-go
- danpalmer 6y ago
  What exactly does your "query engine"/planner actually do? I understand the role that, for example, the Postgres query planner does. Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?
  - fizx 6y ago
    I'm assuming that it's basically a port of GraphQL+DataLoader, so basically using recursive descent to manage hash joins.
  - databrecht 6y ago
    Assuming something in the same vein as fizx with the addition that it's probably very similar to what Join Monster tries to solve: https://github.com/join-monster/join-monster https://github.com/join-monster/join-monster
deleted 6y ago
[deleted]
notJim 6y ago
Is this a bad thing? Are we only interested in funding brand new ideas?

sorenbs 6y ago

This is why we are focusing on the Node and Go ecosystems first :-) If you liked the developer experience in the .NET ecosystem but find yourself needing to work with JavaScript or Go, you'll probably like Prisma.

abraxas 6y ago

Everything is being reinvented from scratch in the JS world. The insistence on unifying into one language means that a lot of tried tested and true has been tossed aside and it's all being rebuilt sometimes with dubious benefit.

hypewatch 6y ago
And perhaps detriment. Nodejs apps are notoriously more difficult to keep secure because of how many npm dependencies are needed for a project and how often vulnerabilities are discovered in those dependencies.
RedShift1 6y ago
And at the end of the day all we do is select, insert, update and delete in some database.
- kevas 6y ago
  True true
pmart123 6y ago
Same thing happened with Python for data science in 2023-2015. ie reinvent SQL using Python DSL.
- yagodragon 6y ago
  Have you tried jupyter notebook + pandas dataframes? You just import a csv and you can explore, clean, manipulate data and make any sort of calculation using a real programming language. On top of that you can use something like seaborn and create visualizations. Then you click print pdf and you're ready. It almost feels like cheating. You can say all you want about how fast,optimized and superior SQL is, but the python experience is way better for almost any time you need to make sense of some data.
  - disgruntledphd2 6y ago
    Not the OP, but I have. I've spent years doing the work that you specify above, and pandas & notebooks are probably one of the least good tools for it. SQL is super fast and useful (and everyone understands it, at least in the data world), while dplyr and ggplot2 are basically a DSL for this work, while pandas is an irritatingly bad clone of base-R which manages to keep the bad parts of both Python and R, while having the good parts of neither. I really feel like you should try Rmd with R if you like the notebook flow, as it's similar but much much better. If you really want to stick with Python, then org-mode is a much better notebook than anything else.
  - pmart123 6y ago
    I have a significant amount of experience with both of them. For pandas, it is fine for initial exploratory analysis (input, plot, reshape and export, etc). However, it's API has inconsistencies and subtle "features" around silent data coercion that make it hard to use in production. Seaborn is much nicer to work with than matplotlib and Jupyter is useful for making interactive presentations. So I believe Pandas/Jupyter have a place, but then there was a tendency to create a Pandas-like wrapper for all data retrieval such as: https://github.com/ibis-project/ibis https://github.com/ibis-project/ibis https://github.com/blaze/blaze https://github.com/blaze/blaze

nikolasburk 6y ago

Some of the ideas we've built into Prisma are certainly inspired by tools in other languages and we've looked a lot at LINQ and the C# ecosystem in general as we designed Prisma! However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se! For example, we're already working on Prisma Client for Golang which is already available in alpha! [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://github.com/prisma/prisma-client-go https://github.com/prisma/prisma-client-go

danpalmer 6y ago
What exactly does your "query engine"/planner actually do? I understand the role that, for example, the Postgres query planner does. Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?
- fizx 6y ago
  I'm assuming that it's basically a port of GraphQL+DataLoader, so basically using recursive descent to manage hash joins.
- databrecht 6y ago
  Assuming something in the same vein as fizx with the addition that it's probably very similar to what Join Monster tries to solve: https://github.com/join-monster/join-monster https://github.com/join-monster/join-monster

deleted 6y ago

[deleted]

notJim 6y ago

Is this a bad thing? Are we only interested in funding brand new ideas?