How far can Prisma take you? (in February 2019)
Tags: prisma, database, graphql
Published: 2019-02-08 11:41:14

---
title: How far can Prisma take you? (in February 2019)
published: true
description: Prisma offers a unique and frankly amazing way to create and access databases. But how far can you go with it right now?
tags: prisma, databases, graphql
---

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:

```graphql
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:

```js
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](https://github.com/prisma/prisma/issues/1263) on migrations which has been marked stale as of a month ago. [The Prisma website](https://www.prisma.io/migrate/) 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](https://www.prisma.io/forum/t/thank-you-nilan/2436). 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](https://github.com/prisma/prisma/issues/3408).
- 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](https://github.com/prisma/prisma/issues/3513).
- 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.