
Prisma 2.0 Beta: Type-safe Database Access - johnnyballgame
https://www.prisma.io/blog/prisma-2-beta-b7bcl0gd8d8e
======
samblr
I was really excited when Prisma1 came out. It would be understatement to
mention that Prisma1 was way overpromised and nothing ever materialised.

With Prisma2, honestly disappointed as it is too little to show for. This is
an ORM like library that supports only couple of databases with database
migrations still in experimental state with broken links for workarounds[1]

Also Prisma2 has half of the features at 'No / Not yet' supported state -
[https://www.prisma.io/docs/reference/database-
connectors/dat...](https://www.prisma.io/docs/reference/database-
connectors/database-features)

Well makes me wonder what's wrong with TypeORM which supports 8 different
databases with full feature support and migrations that work!

[1] [https://www.prisma.io/docs/reference/tools-and-
interfaces/pr...](https://www.prisma.io/docs/reference/tools-and-
interfaces/prisma-migrate)

    
    
      Data Validation
    
      Cascading delete 
    
      Cascading update
    
      Renaming existing table
    
      Renaming existing column

~~~
hau
After working with TypeORM in a quite few projects I can tell that there're a
lot of things that are wrong with it. And TypeORM absolutely doesn't provide
"full feature support" for all 8 databases. Even some basic things are
missing, like joins on delete sql queries in query builder. Simple 'set' mysql
datatype support was missing and I had to add it myself. When it comes to
mapping and data modeling, things are OK most of the time but it breaks when
it comes to somewhat non-basic stuff like STI. Don't get me started on bugs.
Any reasonable alternatives and orm developments are welcome and Prisma2
doesn't take away anything, it's a free software.

~~~
pas
TypeORM seems wonderful for basic stuff, but also in dire need of
maintainers/contributors, at least based on its GitHub issues and docs [0] to
get that last 20% (that takes just as much time as the first 80%).

[https://github.com/typeorm/typeorm/blob/master/docs/query-
ru...](https://github.com/typeorm/typeorm/blob/master/docs/query-runner.md)

~~~
hau
It's actually really good but I don't get the feel of wonder after all those
years together anymore :) Huge db and feature scope definitely keep it away
from any particular completeness despite size and age of the project. Hope to
see something more focused @next.

------
ricardobeat
Was really excited about this until I got to "smart node module". Isn't
changing the contents of a package in node_modules going to break any kind of
caching, de-duplicating etc? In my current project we install node_module`
ahead of time and bake it into a docker image, it is quite common.

~~~
crubier
This is such. A. Stupid. Decision. Indeed.

For example, we use yarn pnp in our codebase so I have absolutely no hope that
it will ever work with Prisma 2.

“Don’t try to be smart” is a very useful mantra for programmers, but Prisma
seems to ignore this.

But hey I don’t want to use it anyway because what I want is a graphql
endpoint not an ORM. We used Prisma 1 and now moved on to graphile.

~~~
nikolasburk
Hey there, thanks a lot for the feedback! As I mentioned in other threads, you
can configure the output location for the generated Prisma Client library [1],
node_modules is just the _default_. The reason why we made it the default is
because it comes closest to what Node.js developers are used to and therefore
fits their workflow and mental model nicely.

Also please read this Twitter thread between the lead Yarn maintainer and our
CEO [2]. The gist is that we're very open to other approaches but this was the
best we've come up with so far after 9 months of experimentation and lots of
feedback from the community. This doesn't get easier by the variety of package
managers out there and the custom workflows they sometimes employ (e.g. wrt
pruning and caching). To put it in the words of our CEO: _we 'd be more than
happy to embrace whatever package manager mechanism would enable this use case
"more cleanly"._

[1] [https://www.prisma.io/docs/reference/tools-and-
interfaces/pr...](https://www.prisma.io/docs/reference/tools-and-
interfaces/prisma-client/generating-prisma-client#specifying-the-target-
location-for-prisma-client) [2]
[https://twitter.com/FredKSchott/status/1245053210852618246](https://twitter.com/FredKSchott/status/1245053210852618246)

------
andy_ppp
It's alright isn't it to get something done fast, until this huge amount of
code that you will never understand bites you in the ass.

I'm secretly rewriting an API written in Prisma 1 into something lower level
that actually allows me to write database queries, optimise what is going on,
look into the _simple_ underlying abstractions if things go wrong and
essentially produce something I can reason about without just hoping nothing
goes wrong under the hood.

Apollo codegen is what you want if you'd like your Typescript frontend to be
consuming the API in a typesafe way.

~~~
crubier
You might want to have a look at Postgraphile. It is nice

------
WhitneyLand
I don’t know why this is not getting more up votes it looks pretty cool.

At first it may seem like yet another attempt to make database access easy
while really making it more complex and harder to maintain.

I haven’t tried this yet, but after reading a couple pages it looks more
interesting than that. For example the fact that it relies on typescript
knowledge which is already widespread, and the fact that it doesn’t require
any server side technology to be installed is a huge advantage.

I’m not sure how it feels in practice, if anyone has experience with it please
chime in.

~~~
Scarbutt
One headline is:

 _Focus on your data – not on complex SQL queries_

Looks like just another SQL DSL trying to make you not learn SQL. TS's
structural typing and plain SQL can get you far into a simpler/robust system
IMO.

Also, the "introspection" part of Prisma seems very crippled, Postgres has so
many useful features for writing application code that it seems wasteful to
just treat it as dumb data store.

~~~
david-cako
I find the process of writing database access functions annoying, and for the
most part, arbitrary and repetitive. ORM functionality that bakes
types/accessors, migrations, graphQL, and even infrastructure into your
codebase is where it’s at. The fact that you are writing your models once and
automatically exposing them as types in any project’s language is a huge
value. I don’t need the same language everywhere, but I want types that plug
together without hassle.

Next generation “serverless” databases will fully abstract object mapping
away. It’s tedious and arbitrary. Even indexing is relatively easy to
automate. I am incredibly excited for what Apple is brewing up right now for
developers.

~~~
servercobra
Is Apple working on some sort of serverless/Firebase type thing?

~~~
applecrazy
I think they're referring to this:
[https://developer.apple.com/icloud/cloudkit/](https://developer.apple.com/icloud/cloudkit/)

It kind of flew under the radar, because it's not super clear how to use it
from the landing page.

------
nojvek
The fact that the returned objects are plain old javascript objects (POJOs)
that's nice.

The smart module bit, it's a bit scary.

basically all I want is a lightweight layer that exposes a promise api to deal
with different databases in a uniform manner.

1) sync to schema.json (this json file contains info of all tables, their
columns, indices and foreign keys). I can sync to db or from db. This lets me
have my state of schema committed to git, and easily move from dev -> staging
-> prod. Django migrations are a giant pain in the ass. Don't do smart fancy
node modules either.

2) autogenerated typescript types, this are nice. But again don't do fancy
node modules, have the typescript types committable to git repo. It makes it
easy to diff and bisect when things fo awry.

3) Super light weight Object -> sql. Access foreign relationships as promises
(always). Make it very easy to debug the generated sql for perf reasons.
Django does some bits well but it's insanely slow at times. Doing things with
raw sql should be just as fast as using a library.

~~~
nikolasburk
Prisma Client is generated into node_modules by _default_ (because that's the
most familiar thing for JS/TS devs), but you can specify any target location
you like for it: [https://www.prisma.io/docs/reference/tools-and-
interfaces/pr...](https://www.prisma.io/docs/reference/tools-and-
interfaces/prisma-client/generating-prisma-client#specifying-the-target-
location-for-prisma-client)

~~~
nojvek
getting a `Not Found`

------
alde
This looks great and should surely cover most of the CRUD needs of simpler
apps and hopefully even more. On the other hand, in my experience such
complicated abstractions eventually leak, especially due to the complicated
nature of the relational model and modern SQL.

For developers not keen on adding a thick indirection layer between the app
and the DB, I have been trying to make raw SQL easier and more reliable to use
directly in TS with PgTyped[1].

In general, I think most people are more than glad to use raw SQL solution
instead of a mapper as long as it has:

1) Realtime parameter/result type inference in their language of choice.

2) Has autocomplete and validation in their IDE

3) Is composable, allowing to join queries/sub-queries..

So far I have been able to implement SQL-in-TS type inference in PgTyped[1]
with autocomplete and validation on the way.

[1]: [https://github.com/adelsz/pgtyped](https://github.com/adelsz/pgtyped)

~~~
nikolasburk
pgtyped looks awesome, fantastic work! We're huge fans of type-safety at
Prisma so anything that makes working with DBs type-safe is right down our
alley! :D

I think one thing that distinguishes Prisma (on the longer run) from a library
like pgtyped is that Prisma will enable more database workflows than just
database access. With Prisma Migrate, you can alter your DB schema and keep a
migration history, Prisma Studio will enable lots of DB workflows on a GUI
level, and Prisma Cloud will have great integrations for teams and larger
scale organizations eventually.

All that being said, because Prisma is a DB _toolkit_ , you can also pick and
choose any tools you like from it. Nothing would e.g. speak against using
Prisma Migrate to run your schema migrations but keep accessing your DB with
pgtyped, in fact I think this would be an awesome combination :)

------
crubier
Why on earth did Prisma take the choice to move away from a brilliant
automatic GraphQL backend as a service to some kind of weird ORM?

Prisma became relevant during their Prisma 1 time, it was one of the first
solutions to automatically generate GraphQL endpoints from DB schemas. It only
had to keep going this way to lead the whole market. But they chose not too,
and competing solutions such as Graphile beats prisma 1 so much now.

Meanwhile they have been stuck for 2 years in their new weird direction of
Prisma 2, with no results to show for, and no clear vision. The GraphQL server
is gone, even though it was central to their product. Who cares about yet
another ORM? I can generate types from any GraphQL endpoint automatically
anyway!

------
Sytten
I have been using it for a new project and it really is awesome. I can't
imagine going back to an ORM or another query builder now.

~~~
efrafa
Been using it as well on a side project together with nexus and nexus-prisma
and it's really a joy to work with.

~~~
tylerandersen89
Same we've been using Graphcool/Prisma 1 for 2 years. Has been single handedly
the biggest reason for our speed of development. We absolutely love the
generated types and automatic introspection, everything is just documented
automatically, it's truly revolutionary.

------
phiresky
This seems to be solving mostly the same problem as the following libraries:

[1] [https://github.com/phiresky/ts-typed-sql](https://github.com/phiresky/ts-
typed-sql) [2]
[https://github.com/Ff00ff/mammoth](https://github.com/Ff00ff/mammoth) [3]
[https://github.com/AnyhowStep/tsql](https://github.com/AnyhowStep/tsql) [4]
[https://github.com/travigd/vulcyn](https://github.com/travigd/vulcyn)

A query in one of those looks like the following:

    
    
        const rows = await select(list.id, list.createdAt)
          .from(list)
          .where(list.createdAt.gt(now().minus(`2 days`)).or(list.value.eq(0)))
          .limit(10);
    

The resulting type of `rows` is inferred by TypeScript to the corresponding
correct type (`{id: string, createdAt: Date}`)

Prisma solves the problem by generating code, while all of these do it
completely in type-level within typescript. Prisma also seems to introduce its
own query language, while the above linked libraries stay closer to SQL.

[1] was written by a friend of mine and I'm using it in production to great
success. I wouldn't recommend it though because it has repeatedly broken with
new TypeScript updates since it uses very complex type structures and the dev
has basically given up on it due to the complexity.

[2] is probably the most production-ready, though it has some design choices
I'm not sure about.

[3] is the most well-designed, and can handle complex scenarios (including
differentiating between join types etc). But it's incomplete so far.

[4] I have not used.

Pure type-level has the advantage of not adding a compile-step and keeping
everything in a tool you already know. But all of the above have the
disadvantage that the resulting type structures are very complex - most TS
devs would have a hard time understanding the internals of the libraries and
the resulting type errors can be unreadable. They can also cause the TS
compiler to slow down significantly (in the past [1] had exponential compile
time when adding a new column, though this has been fixed).

Also, since the TS compiler uses heuristics in multiple places and the type
system is not sound, Microsoft has introduced regressions that have broken [1]
in every other release.

~~~
timmy-turner
Thanks for sharing these projects. So far I only knew tsql.

I'm in the avoid code generation camp as well as typically my build processes
are complex enough and don't need another step.

But I am not quite satisfied by the existing query generators. Also after
having read [https://github.com/jawj/mostly-
ormless/blob/master/README.md](https://github.com/jawj/mostly-
ormless/blob/master/README.md) I wanted to put Postgres' `json_agg` function
into use as it looks like it is simplifying a lot of the nested objects stuff
one serves over REST APIs.

So I designed my own [https://github.com/hoeck/typesafe-query-
builder](https://github.com/hoeck/typesafe-query-builder) \- with special
support for `json_agg` and `json_build_object`. Its working already in
production and for me, the dev UX is unprecedented in working with database
code. Typechecks and autocompletions really boost it. But to be honest, I'm a
bit worried about Typescript compiler bugs and compilation times when the
project grows.

------
johnnyballgame
Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project and
it's been a pleasure to work with.

~~~
salimmadjd
I'm very curious. Can you pleas share some specifics.

~~~
nikolasburk
[https://twitter.com/mojombo/status/1244877311196856320](https://twitter.com/mojombo/status/1244877311196856320)

------
zaiste
Those, who prefer a more old-school approach, may find PgTyped [1]
interesting: you write SQL and you have typings in TypeScript. Still very
alpha, but promising.

I'm working on integrating PgTyped into Huncwot [2]

[1]: [https://github.com/adelsz/pgtyped](https://github.com/adelsz/pgtyped)
[2]:
[https://github.com/huncwotjs/huncwot](https://github.com/huncwotjs/huncwot)

------
eitland
Edit: please read nikolasburk's answer below which makes a lot of sense. The
docs weren't an attempted attack on all ORMs but rather a description of
problems with certain Javascript ORMs.

My original post:

This looked interesting at first but this reads like someone either don't know
a thing about JPA and Entity Framework or are deliberately misrepresenting
them:

> ORMs are libraries that map tables in your database to classes in your
> programming language. Prisma on the other hand is an auto-generated query
> builder that exposes queries which are tailored to your models. All Prisma
> Client queries return plain old JavaScript objects.

Yep, tables maps to classes, but guess what gets returned?

Plain Old Java (or CLR) Objects. And guess what: Thanks to those languages
well thought out design and extensive metaprogramming abilities this can all
be done without making up a new language also.

This is probably the harshest I've been here on HN, but smearing good
solutions really doesn't sit well with me.

~~~
nikolasburk
Hey, thanks a lot for the feedback (and I've seen harsher words on HN, so no
worries)! I wrote most of the docs, so more than happy to take any feedback to
see where it can improved!

What I'm mostly trying to refer to are ActiveRecord style ORMs in the Node.js
ecosystem (such as Sequelize and TypeORM). With those libraries, you often
have model objects that can get really complicated to work with, these are not
plain objects but implement lots of additional behaviour for storage and
retrieval of data, often times business logic as well. Compared to that,
working with plain objects (which are statically and structurally typed) is a
fundamentally different approach that's hopefully easier to reason (at least
that's what I've found from my personal experience).

~~~
eropple
I don't really understand the claim you're making here--you have to go out of
your way in TypeORM to get ActiveRecord objects instead of plain JavaScript
objects. The happy path is pretty firmly in data-mapper territory; as an
example, for all the shade I will happily fling NestJS's way they just hand
you a Repository and tell you to get on with your day.

There's also stuff like Objection.js (which works well in TypeScript), too.

I don't dislike Prisma, but the framing is really strange to me.

~~~
PaulMest
Could be off-topic for this thread... but what shade would you like to throw
NestJS's way? Or do you have a write-up somewhere else, by chance?

~~~
eropple
\- I think it comprehensively misunderstands and mis-implements a lot of
things that are important. Their “microservices” boondoggle is a whatever RPC
mechanism that has no real reason to exist, their CQRS library expects the
world to be a single node, their OpenAPI library is vestigial and completely
separates the generation of documentation from actually validating inputs.
Most of the things outside of core are rotated about 45 degrees away from
where you’d expect with a holistic understanding of a web application. Stuff
built by somebody who heard of a problem, not felt a problem.

\- I think that the core team is bad at and refuses to improve at
communicating with its community via roadmaps. Huge changes just appear,
including literally breaking changes within a given major release, with little
to no warning.

\- I think they don’t respect what community they do have, building completely
new, blessed-by-the-core-team libraries that step on existing open-source
solutions in the NestJS ecosystem mostly just so the package can say
“@nestjs/“ at the front of it. (Top of mind example is “@nestjs/schedule”,
which is a worse take on “nest-schedule.") There isn't much personal incentive
to build community tooling if the core team will swoop in and go "mine now!"
without so much as a prior-work credit and it's disrespectful besides.

\- They continue to build their own tooling that steps on the accepted norms
and systems in the Node community. The NestJS CLI now incorporates "monorepos"
that aren't Lerna or Yarn ones; they're also pushing developers to use it as
their primary way of building applications, rather than invoking tsc, with the
dangly carrot of "we'll write plugins for it [rather than using one of the
existing ways to better handle extended compilation]". It feels like a lock-in
play for future monetization (there's open rumors that Kamil is very focused
on monetization, which--you do you, but as Rails and Django and even Spring
showed us this stuff seems to really work better if you care about it existing
to exist, and you make money off of using it) and the lack of community
roadmap makes assuaging those concerns very much not a priority of the core
team.

I was a big booster of NestJS a year ago and I’ve written a bunch of modules
for it. I was even a personal donor to the project's Open Collective, it's the
only project I've ever done that for. But I do not use NestJS for new projects
because I have no confidence in the design or the leadership there and I don’t
think it’s a wise use of my time anymore.

~~~
seymon
What are you using now for your new projects instead of nestjs?

~~~
eropple
I'm writing a framework atop Fastify at the moment. My intention is to address
a number of deep-seated technical problems I see with NestJS and present a
holistic view of an _application_ , rather than a _web app_ , that can be used
to more clearly structure and maintain my projects. I don't intend to monetize
it, so I don't feel compelled to work outside of the normal NodeJS ecosystem
and if there's any interest I intend to build a binding steering committee
rather than run the risk of having a non-communicative "B"DFL.

------
kemcho
I LOVE massivejs[1], a query builder type library for Postgres in nodejs. Is
prisma2 like massivejs but for typescript?

If someone’s tried both, would love a quick comparison :)

[1] [https://massivejs.org/](https://massivejs.org/)

~~~
nikolasburk
Massive is great and we certainly took some inspiration from it (in fact we're
friends with Dian, the author of Massive and are fans of her works).

The level of type-safety when using Prisma Client with TypeScript is indeed a
major factor that sets Prisma apart from other DB libraries in general (not
Massive in particular).

Would also love to hear what other people think of the two in comparison! :)

------
CraftThatBlock
How does this compare to TypeORM? First time hearing about this project, and
it looks interesting

~~~
nikolasburk
Nikolas from the Prisma team here.

The most important thing to note here is that Prisma Client is not an ORM! [1]

Prisma doesn't map classes to tables as ORMs do and therefore doesn't suffer
from the object-relational impedance mismatch. Prisma Client queries return
plain old JS objects, which makes it really easy to reason about queries and
returned data.

Prisma also has a query engine [2] that's implemented in Rust. This is being
developed separately from the TS/JS layer above (so that in the future Prisma
can support other languages as well).

Prisma also generally provides stronger type safety than TypeORM. For example,
you get full type safety even for partial queries [3], you can find an example
for what this looks like in this video [4].

Let me know if you have more questions about this :)

[1] [https://www.prisma.io/docs/understand-prisma/prisma-in-
your-...](https://www.prisma.io/docs/understand-prisma/prisma-in-your-
stack/is-prisma-an-orm)

[2] [https://www.prisma.io/docs/reference/tools-and-
interfaces/pr...](https://www.prisma.io/docs/reference/tools-and-
interfaces/prisma-client/query-engine)

[3] [https://www.prisma.io/docs/reference/tools-and-
interfaces/pr...](https://www.prisma.io/docs/reference/tools-and-
interfaces/prisma-client/advanced-usage-of-generated-types)

[4] [https://youtu.be/LggrE5kJ75I?t=40](https://youtu.be/LggrE5kJ75I?t=40)

~~~
pvg
In the first document, all the links in the comparison table link back to the
document itself instead of the documentation for the things mentioned.

~~~
nikolasburk
Thanks, will get that fixed!

------
hleszek
We started using Prisma 1 for our project and ran really fast into missing
features that are really missing for a complete product.

But with a few workarounds it was possible to make it work and is quite nice
to use.

Example of missing features:

Primary key as a combination of two relational models:
[https://github.com/prisma/prisma1/issues/3553](https://github.com/prisma/prisma1/issues/3553)

Database Constraints
[https://github.com/prisma/prisma1/issues/728](https://github.com/prisma/prisma1/issues/728)

Cascading Deletes
[https://github.com/prisma/prisma1/issues/1262](https://github.com/prisma/prisma1/issues/1262)

Upsert
[https://github.com/prisma/prisma1/issues/2194](https://github.com/prisma/prisma1/issues/2194)

On delete restrict
[https://github.com/prisma/prisma1/issues/2701](https://github.com/prisma/prisma1/issues/2701)

Mutation CreateOrConnect
[https://github.com/prisma/prisma1/issues/3724](https://github.com/prisma/prisma1/issues/3724)

Improving performance with Indexes
[https://github.com/prisma/prisma1/issues/1300](https://github.com/prisma/prisma1/issues/1300)

Multiple field unique constraint
[https://github.com/prisma/prisma1/issues/171](https://github.com/prisma/prisma1/issues/171)

Interface types
[https://github.com/prisma/prisma1/issues/83](https://github.com/prisma/prisma1/issues/83)

Embedded Types
[https://github.com/prisma/prisma1/issues/2836](https://github.com/prisma/prisma1/issues/2836)

Declarative support for multi-field unique constraints
[https://github.com/prisma/prisma1/issues/1237](https://github.com/prisma/prisma1/issues/1237)

Support union types
[https://github.com/prisma/prisma1/issues/165](https://github.com/prisma/prisma1/issues/165)

Transactions for multiple mutations
[https://github.com/prisma/prisma1/issues/74](https://github.com/prisma/prisma1/issues/74)

~~~
nikolasburk
Hey! Thanks a lot for sharing this, a lot of the features you mention here are
already possible with Prisma 2.0 (or will be in the future). Would love to
hear your thoughts on the new version :)

------
heymartinadams
I’ve been using Prisma in development and highly recommend it. There’s nothing
like it out there!

------
propelol
How does it differ from Hasura?

~~~
nikolasburk
Prisma and Hasura are very different!

Prisma is a _database toolkit_ that's used by application developers to
develop server-side applications in Node.js and TypeScript (e.g. REST APIs,
microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a
database). The main tool Prisma Client is a _query builder_ that's used to
_programmatically_ send queries to a database from Node.js/TS.

Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for
your database. This GraphQL API is typically accessed by frontend developers.
That setup can be great when your application doesn't require a lot of
business logic and the CRUD capabilities that are exposed in the GraphQL API
fit your needs (though I believe you can add business logic in Hasura by
integrating serverless functions).

With Prisma, you're still in full control of your own backend application and
can choose whatever tech stack you like for developing it (as long as it's
Node.js-based, though Prisma Client will be in available in more languages the
future)!

By the way, we also love GraphQL. We're currently brewing a new "GraphQL
application framework" that can be used on top of Prisma. That way it will be
possible to auto-generate resolvers for Prisma models to reduce the
boilerplate you need to write, while still keeping the full control of your
GraphQL schema.

You can learn more about this here:
[https://www.nexusjs.org/#/](https://www.nexusjs.org/#/)

~~~
gavinray
I want to point out a defining characteristic between Hasura and Prisma:

While Hasura does work to auto-generate a GraphQL API from an existing
database, it also has a web console that lets you build your database models
and relationships, plus permission logic and authorization point-and-click.

Custom business-logic outside of the CRUD it generates is done by writing HTTP
endpoints that you can wrap as "Actions", which it generates GraphQL types and
resolvers for as part of it's schema. IE, you will want to define an API
endpoint for login/signup, and declare these as "Actions", which you can then
query from Hasura's schema.

An SDK/toolkit can be auto-generated from the GraphQL schema Hasura produces
using graphql-code-generator, giving you strongly-typed
query/mutation/subscription components in your desired frontend framework (IE
React/Vue/Angular + Apollo/urql etc.)

Scheduled tasks/cronjob functionality is under development as well.

Prisma gives you a "finer grained" set of tools to "build" an application
with, where Hasura kind of just hands you the whole thing (though in an
opinionated fashion).

------
timmy-turner
Not getting warm with any query/ORM library out there.

My own take of interfacing with an SQL database with Typescript: a query
generator that uses mapped types a lot to infer result set types from queries
and a schema file.

[https://github.com/hoeck/typesafe-query-
builder](https://github.com/hoeck/typesafe-query-builder)

Not sure if thats a good idea and if the Typescript inference even scales that
well when using lots of tables.

Any feedback and criticism would be welcome.

------
adsharma
Why generate types from a query when you can write a schema for your objects
and then write queries where types can be inferred based on object types and
query constructs?

Some ideas from a recently open sourced project:

[https://github.com/facebookexperimental/fquery/blob/master/t...](https://github.com/facebookexperimental/fquery/blob/master/tests/test_operators.py)

------
ronlobo
Makes sense, non-type-safe language, we can push type safety guarantees to the
persistence layer by coupling the domain models to the type-safe data models.

------
zeroz
Looks very interesting. At the moment we're using a Node.js + Postgres +
Sequelize ORM [1] + Express setup in production and are very happy. All lot of
features and very robust setup.

Any production ready experience with Prisma?

[1]: [https://sequelize.org/v5/](https://sequelize.org/v5/)

------
g_delgado14
Hi there, I'm a prisma 1 user and am wondering if there is thorough docs on
how to transition over to prisma 2.

Also what breaking changes or not-yet-implemented features of prisma1 should I
be aware of.

\----

Edit: I see there's a "I currently use Prisma 1, what should I do?" section.
Any other info would be greatly appreciated.

~~~
nikolasburk
Hey! We will provide upgrade guides and dedicated tooling [1] in the next
couple of weeks to ensure a smooth transition for current Prisma 1 users!

You can find more context on isprisma2ready.com.

[1]
[https://github.com/prisma/prisma/issues/1937](https://github.com/prisma/prisma/issues/1937)

------
nailer
Is mongo support in yet? I tried the Prisma2 beta a couple of months ago and
it was still on the way.

~~~
etelsv
We do not have Mongo support in Prisma 2 at this point, but we have a GitHub
issue to track it as a feature request:
[https://github.com/prisma/prisma/issues/1277](https://github.com/prisma/prisma/issues/1277)

------
beart
I wish I was not stuck on Ms SQL server. The JS ecosystem tends to ignore it
or treat it as a second class citizen. Would love to check this out otherwise.

------
johnnyballgame
Will SQL Server databases be supported at some point?

~~~
nikolasburk
We're indeed planning to broaden the support for various databases in the
future (e.g. already looking into MongoDB and FaunaDB).

If you have a specific DB in mind that you'd like to see supported, please
open a feature request here:
[https://github.com/prisma/prisma/issues/new?assignees=&label...](https://github.com/prisma/prisma/issues/new?assignees=&labels=&template=feature_request.md&title=)

~~~
ceohockey60
Good to hear. Curious why Fauna is being looked into by your team, since it
appears to be a much newer database (and also not open sourced AFAIK)? Mongo
makes sense given its obvious popularity.

------
kemcho
Looks cool! Is there a business model around prisma?

~~~
nikolasburk
We are planning to eventually add commercial cloud services to make Prisma/DB
workflows easier (especially for teams and larger organizations). The current
OSS database toolkit will remain free forever!

More info here: [https://www.prisma.io/docs/more/faq#how-much-does-
prisma-20-...](https://www.prisma.io/docs/more/faq#how-much-does-
prisma-20-cost)

------
redka
Does this work with pnpm since node_modules/@prisma/client changes based on
the project it's in?

~~~
pantharshit00
It works fine with pnpm. The client package has a postinstall hook that
generates the client after you install it.

------
rlili
Is real-time subscriptions on the roadmap? It's the most killer feature of
Hasura and Postgraphile IMO.

~~~
nikolasburk
Nikolas from Prisma here, a realtime API for Prisma is certainly on our
roadmap – as Prisma doesn't provide a GraphQL interface, this most likely will
not come in the form of GraphQL subscriptions though but another
(programmatic) realtime API.

However, using Nexus [1] on top of Prisma, you'll be then be able to turn
Prisma's realtime API into GraphQL subscriptions. All of this is quite a bit
further down the road, but certainly on our radar and part of future plans!

We have an open feature request for that here:
[https://github.com/prisma/prisma/issues/298](https://github.com/prisma/prisma/issues/298)

[1] [https://www.nexusjs.org/#/](https://www.nexusjs.org/#/)

------
fataliss
So is that some sort of "ActiveRecord" for Javascript? It looks pretty darn
cool.

