> My first instinct was to say type safety, but you don't really get that with JS either way.
Correct, but the main experience we are supporting is TypeScript, which has a beautifully designed type system.
> Maybe it would be popular for new engineers that don't feel like learning SQL. Same reason why MongoDB got popular.
We have more and more senior engineers who want to use Prisma, as they just realized that writing SQL by hand is a waste of time.
Let's be honest - learning SQL is still a great skill. Data analytics etc - there are great use-cases.
But if you want to get stuff done and scale your team when building an _application_ - you should have a data layer.
That's what Facebook, Lyft, Airbnb etc did - they have a dedicated data layer and a team working on that.
Do you think an application engineer at Facebook writes SQL?
No. Of course not, it would be a total waste of time to let them touch such a low level. It would not allow facebook to scale to where they are, if everyone would write direct SQL.
Now the thing is, most small teams don't have the capacity to write a really performant awesome data layer with caching, deduping etc.
That's where Prisma comes into play - Prisma gives the weekend producthunt warriors, but also the enterprise teams (like Tryg) a way to abstract away the database.
But it's just a library you say?
That's true. So in that sense, Prisma is not really a "layer", a different component in your architecture that you can horizontally scale.
For that - stay tuned. The "client" part can already easily be separated from the "query engine" part (which btw is written in Rust) because they speak http. But step by step. For most people, being able to install an npm dependency is the most important part here.
But one thing you can already get used to - Prisma will stick around and _not_ just be a thing that new engineers who don't feel like SQL use.
Hey Jeremy, thanks for sharing this awesome article!
Do you think this is also applicable to classify 1. readability and 2. entertainment/fun of a text? Thanks!
> Maybe it would be popular for new engineers that don't feel like learning SQL. Same reason why MongoDB got popular.
We have more and more senior engineers who want to use Prisma, as they just realized that writing SQL by hand is a waste of time.
Let's be honest - learning SQL is still a great skill. Data analytics etc - there are great use-cases.
But if you want to get stuff done and scale your team when building an _application_ - you should have a data layer.
That's what Facebook, Lyft, Airbnb etc did - they have a dedicated data layer and a team working on that. Do you think an application engineer at Facebook writes SQL? No. Of course not, it would be a total waste of time to let them touch such a low level. It would not allow facebook to scale to where they are, if everyone would write direct SQL.
Now the thing is, most small teams don't have the capacity to write a really performant awesome data layer with caching, deduping etc.
That's where Prisma comes into play - Prisma gives the weekend producthunt warriors, but also the enterprise teams (like Tryg) a way to abstract away the database.
But it's just a library you say? That's true. So in that sense, Prisma is not really a "layer", a different component in your architecture that you can horizontally scale.
For that - stay tuned. The "client" part can already easily be separated from the "query engine" part (which btw is written in Rust) because they speak http. But step by step. For most people, being able to install an npm dependency is the most important part here. But one thing you can already get used to - Prisma will stick around and _not_ just be a thing that new engineers who don't feel like SQL use.