There comes a point during a solo project where you need to work with something you’re just not that good at. In my case, that’s databases. I had two options:
- A. Do the right thing and finally learn SQL
- B. Remain blissfully ignorant and use something that uses my existing knowledge and allows me to get on with it.
The last few years I’ve worked a lot with GraphQL clients and APIs. Prisma is a tool that provides a way to turn a bit of GraphQL SDL like this:
type User {
id: ID! @unique
name: String!
email: String!
posts: [Post!]!
friends: [User!]!
}
type Post {
id: ID! @unique
title: String!
body: String!
isDraft: Boolean!
author: User!
}
into a running database which you can read/write to in your own apps like this:
let newUser = prisma.createUser({
name: "Sally Moobles",
email: "sally@moobleit.biz",
});
let newPost = prisma.createPost({
title: "My Great Post",
body: "I'll finish this later…",
isDraft: true,
author: {
connect: {
id: newUser.id,
}
}
});
From writing a single SDL you get a database and a client to read and write to it from. It can’t be overstated how cool this is! It works as advertised — you can go from nothing to ORM in a very short space of time, have a choice of database technologies to choose from (e.g. Postgres), and the generated clients are great in combination with a language like Typescript where you can get autocompletion for all the different operations. This is going to be huge.
But this post is about Prisma as of February 2019, and how far it can take you now. Below are a few reasons which prevent it from being something I’d want to take into a production environment today.
No data migrations
Prisma will automatically migrate your database when you change your SDL and run prisma deploy. But what it doesn’t know how to do is migrate data. This means that non-trivial schema changes, such as creating a new required field or changing a field type, have to be handled manually. There are no Rails-esque up or down migrations which tell Prisma what data should look like in the next schema. In the case of a new required field you would first create the field as optional, fill in all the data using a script, and then flip on the required flag and redeploy.
When you’re working on something alone with dummy data this is… bearable. Just. But how can this approach possibly work with a team of people, working on different branches, deployed to different environments? How do you do CI? The answer: very tediously and slowly.
There is an issue on migrations which has been marked stale as of a month ago. The Prisma website suggests that in the future, there will be a better system. When is it coming? What should you do now instead? It’s really not very clear.
And this leads into the other biggest problem I think Prisma has right now:
Support / Communication problems
It’s hard to know what the roadmap is for Prisma, what their priorities in terms of features are, or whether the features many people are asking for are considered important. There are lots of issues which offer specs for new features, but which have not been updated for a long time.
There’s no doubt that the Prisma team is working hard, but the lack of regular communication on their work and plans inevitably affects your confidence as an end user. It makes me think, well this is fun but I am probably going to have to do this the old fashioned way eventually.
They also seem to have a bit of a problem with support. Because Prisma positions itself as an easy way to do something, it attracts a lot of beginners — a great thing — who ask a lot of questions. On their Slack, forums and Github it looks like most of these questions go unanswered. In the past Prisma had someone dedicated to support who left. They should pay whoever does that job next very well!
A non-exhaustive list of smaller things I bumped into while working on my project
- Non-trivial unique constraints. Using the SDL you can specify that certain fields (e.g. User’s emails) should be unique, but you can’t do things like say all Post titles should be unique within the context of their user. This will apparently be addressed by an enigmatic Datamodel v2.
- No case-insensitive search for text fields
- Exposing connections. Connections are a spec for exposing long lists of data which you’d like to paginate through or only capture a small part of. Exposing connections retrieved from Prisma to your own client-facing GraphQL API requires some weird workarounds.
- Using the generated Prisma client with Typescript is great but figuring out how to use it with Javascript is painful. The method names are generated from the names of your fields in your SDL so you have to figure out what the names are and what kind of arguments they take by yourself. The arguments especially can be very, very deep and are easy to mess up.
Finally
The reason I’m writing this is because I want Prisma to be the only thing I need to use so badly. The points above are why I don’t think I can do that right now. But there are a lot of reasons to believe it’ll get there.
But man, waiting sucks.
Top comments (3)
Hi Sam 👋 I'm Nikolas from the Prisma team.
First of all, it's great to hear that you appreciate the value a tool like Prisma has!
I would like to address your concerns about the state of Prisma today. Your criticism in general is absolutely on point and some things you've mentioned are exactly the ones highest on our priority list at the moment.
No data migrations
Right now our migration system is overly simple, which on one hand is good because it's very easy to use, but on the other hand bad because it comes with some major limitations. You've pointed to an older GitHub issue that requests a more sophisticated migration system. We've actually just started speccing out our new migration system and want to evolve the spec through our RFC process. You can find all details here.
The new migration system will be a lot more powerful and allow for advanced migrations that you sometimes need to perform in more complex production environments. I would love to hear your thoughts on it!
Support / Communication problems
I apologize for the lack of communication on our end. We've been meaning to publish a roadmap for our engineering plans for quite a while, but for various reasons have never gotten around to actually doing it. I realize how important a public roadmap is for developers that are betting on Prisma and want to use it in production. I'll raise this point internally again and will push it as much as I can!
Regarding support, I'd be interested to hear concrete instances where you feel questions have been unanswered. We have a dedicated support team that's picking up questions in our forum and on Stackoverflow regularly. Whilst not always being immediate, the questions in the forum are usually answered on the day they're posted (sometimes the day after, depending on time zones...). GitHub issues are being processed and triaged every day. Questions in Slack are rarely answered by our support as we see Slack more of a place for the community to interact than for actual Prisma support (see our community guidelines here).
Finally, there's also
support@prisma.iothat you can always contact when you're running into issues. We're also hiring to increase our support capacity.Smaller issues
Non-trivial unique constraints
As you mentioned, the datamodel v1.1 (formerly called datamodel v2) is indeed the solution to this. It will most likely be available in beta in ~3-4 weeks. Together with the new migration system, the datamodel v2 is one of our highest priorities at the moment.
No case-insensitive search for text fields
This is indeed a limitation of the current Prisma API. There's already an open GitHub issue where you can track the progress. Here's a workaround that shouldn't impose too much overhead.
Exposing connections
This actually is fixed by now and connections can now be used with the Prisma client. Combined with the new GraphQL Nexus, it's now fairly straightforward to implementation Relay-style pagination with the Prisma client.
Using the generated Prisma client with JS
We're huge fans of TypeScript and strong believers that it will eventually become the standard to build apps for the Node ecosystem. Nevertheless, we want to enable great DX no matter if developers are using TS or JS today. To my knowledge, it's possible to have auto-completion for nested types even with JavaScript, because we include the TS type definitions in the generated JS client code as well. Other than that, this is a job of our documentation to get right, and we're aware that we have a bit of work to do in that regard (although the Prisma client API docs currently already cover the vast majority of the API, including practical examples).
To address your concern about using Prisma in production, I want to state that we have many developers that are happily using Prisma in production today. You can e.g. read about Hyrecar (recently IPOed) or Labelbox (funded with $3.9mio) on our blog.
Thanks again for all your constructive feedback, we really appreciate it! We know that people have high expectations for Prisma and are working hard on fulfilling them. That being said, our team is still small and capacity therefore sometimes limited, but we're looking to grow so I want to mention that we're hiring for anyone who's interested in working on highly technical database and API topics 💪
UPDATE, February 28
We have just published our public roadmap. Our main goal with the roadmap is to provide visibility in the current efforts of the Prisma engineering team and make Prisma users aware of upcoming changes. I hope this addresses some part of your concern about our public communication! 🙏
Hi Sam!
Just stumbled about your article while searching for the possibility to do a Postgres full-text search with prisma (I don't have a solution yet).
But I wanted you to know that case-insensitive search for Postgres is now a preview feature of the latest release: github.com/prisma/prisma/releases/...
(There's already a bug fix release 2.5.1 at the time I'm writing this)
Greetings!
Try mode