https://www.prisma.io/ logo
Join Slack
Powered by
We have been using prisma for 7 months now and the...
# orm-help
c
We have been using prisma for 7 months now and the more I use it, the less I see a need for it. Would love to discuss its use case
j
as a dev, I like that i can get all the basic crud operations build very quickly using forwardTo. It lets me spend more time working on things that matter more.
r
@cb would love to hear your point of view.
c
the biggest hiccup I see is that if your app is not public, you need to place a server in front of prisma, which effectively reduces prisma to an sdk over mysql. There are many existing schema generation and api modules available out there without having to run a docker instance.
h
For us, the large benefit is 
prisma-binding
, being able to pass the user’s 
info
object to the DB is amazing
Although, if your app schema becomes a *super*set of your DB schema, it can get a little tricky, requiring custom schema transforms to work
Otherwise, you’d have to start building your own custom parser that can translate the user’s requests into a DB query - how would you go about that?
j
we run the yoga and prisma server together, and deploy a single docker image to aws lambda. pretty slick. Like this, it's more of an orm than a second server layer.
running a docker instance is not a disadvantage
h
“single docker image to aws lambda” .. what? 🙂
j
oops, i meant now.sh
h
Ah, OK 🙂
j
we do have another project running on a single lamda though
h
I’d recommend you don’t. For one, seperation of concerns. Second, Prisma doesn’t scale horizontally unless you set it up with a primary and a lot of secondaries (https://github.com/prisma/prisma/issues/2850)
Furthermore, I’ve recently found that Prisma is quite memory hungry, and often requires more RAM than the largest instances Now provides has, 512MB
So I’d recommend you host the Prisma server on a machine with at least 1GB of ram - otherwise, your performance is going to suck
Also, Now is moving towards serverless and Lambdas, and away from Docker - so you might want to look elsewhere than Now for your Prisma hosting
a
Another usecase I see for prisma is actually as a prototyping tool. It lets me set up a SQL database that can then be filled with whatever data I like and it lets me experiment with stuff on the frontend. Granted, you shouldn't go to production with a prisma backend, but there's certainly a usecase for getting a proposal to a client in a week or so
h
The golden solution with horizontal scaling: Kubernetes and RabbitMQ. If you want to go for vertical scaling, I recommend Heroku or Digital Ocean
@Arnab - Why not use Prisma in production?
a
You could and should use prisma in production, but not as your backend.
h
And if all you need is a prototyping tool, I’d recommend the Graphcool framework - it’s even faster to work with
a
It should be behind your API.
h
Ah, of course 🙂
a
I prefer prisma because I can later put it behind my backend, and therefore whatever work I put into the prototype is not wasted
j
interesting about the scaling. thaks for sharing that link
a
And not only that, a lot of the project proposals we have are secret enough that we don't want to put them anywhere but on our own private servers. So graphcool has never been an option.
Unless of course, it is possible to self-host graphcool (?)
j
you can self-host yoga + prisma
h
Don’t think so - Graphcool would be for prototyping only, although I am actually running a production app on it right now 🙈 It was built before Prisma existed
a
it says you can host it locally using docker
Does that mean... we can deploy that docker image to any linux machine?
j
do it
c
we use a distributed database as our datastore. If scaling prisma requires 1GB instances, where is the value prop? Why not just do the things prisma does with an ORM module/gem/whatever python uses?
When you place an app server in front of prisma, its doing the heavy lifting, which means prisma is only transforming gql into mysql commands. On the surface, for us, it doesnt seem to be doing much at all.
It also lacks the subtlety an ORM provides to make efficient queries to the backend. With some of our aggregate reports we have no choice but to load excessive amounts of data into memory and aggregate it there, even when the syntax is quite straightforward in mysql
Everyones comments above about prototyping speed are on point.. we enjoyed those benefits greatly while getting this project up to speed. Now that we are getting into heavy data use features, we are struggling.
a
Eh
Of course you have a choice. You can use raw SQL in your API that you put in front of prisma. No need to have it in memory
There is nothing that says that you absolutely need to leverage prisma for aggregation
Open in Slack
PreviousNext
Powered by