Absinthe vs Prisma

I’ve recently discovered GraphQL and am very motivated by it. I am also very, very motivated to do Erlang and/or Elixir development.

I’m strongly considering porting my Meteor application to a hybrid React/GraphQL architecture.

Since I am very dedicated to Erlang/Elixir, I’ve taken a look at Absinthe and so far I like it. However, I have also looked at Prisma and it seems so easy - almost magic. Admittedly, I’ve barely scratched the surface on both Absinthe and Prisma.

I’m definitely biased towards using Absinthe. Can anyone with knowledge of both of these share any pros and cons to help me make my way through this?

Many thanks…

3 Likes

What’s Prisma? Do you mean https://github.com/graphcool/prisma?

1 Like

I recently evaluated this myself.

Prisma seems to promote speed for development. But as I started to get further into it, it became clear I needed server side functions (ie. to talk to stripe) (which you can also do with graphcool / serverless)… but it quickly stopped becoming ‘super fast’ to do. Developing in elixir is fast already. All in for a normal-sized app, I’m guessing elixir is faster to develop in.

Also, I got a bit confused when it came to deploying an app using prisma. I think you end up needing to deploy 3 separate services between front end, functions and prisma.

With graphcool, you get a few loosely tied parts that work together pretty well… but you definitely still need to invest time to learn it to do almost anything beyond just getting started.

IMHO both Absinthe and graphcool are very, very good overall. So neither is a bad choice. I ended up with Absinthe / phoenix. Just one thing to deploy and I feel like I have more control. Also, personally I’d rather be better at elixir/absinthe than graphcool’s framework.

5 Likes

Based on a brief evaluation, Graphcool looks to be a neat solution if you want hosted support for your API. Otherwise, as part of an Elixir server, why would you not just use Absinthe? I’ve recently used Absinthe to support a fairly complex mobile data gathering application. Development was pretty quick, so it would seem hard to justify giving attention to yet another technology such as Prisma. I’m happy to be corrected if I am missing something.

3 Likes

My entry point into it has been https://www.prismagraphql.com. Here is the material that I worked through: https://www.prismagraphql.com/docs/tutorials/prisma-basics/getting-started-ouzia3ahqu.

Thanks

I’ve done a lot of work with both Prisma and Absinthe. Here’s my take.

For quick background, Prisma is built on Scala/Sangria and uses MySQL, all Dockerized. They will soon provide adapters for Postgres, Mongo, and Elastic Search.

Prisma abstracts the database layer into a GraphQL API. You still need a GraphQL server. If you’ve worked with GraphQL schema stitching before, it really is schema stitching a database GraphQL application into your main GraphQL application.

It has two main advantages. The first is database migrations. For instance, when you declare a two SDL types, e.g.

type Post {
 id: ID!
 title: String
 likes: Int
 comments: [Comment]!
...
}

type Comment {
 ...
 text: String!
 post: Post!
}

Prisma infers the one to many relationship and migrates the data base accordingly! Awesome.

Second, it generates much of the GraphQL boilerplate. For instance, for the above types, it will automatically generate a PostsConnection type. Simply import the type (e.g. graphql-import package) and you’re off and running with GraphQL connections. Hand wringing that in Absinthe (or any other server implementation) can take some time. And it generates all CRUD functions, e.g. updatePost.

For server packages, Absinthe and Elixir can’t be beat. However, I typically don’t like ORMs and tend to fight against them. I kept butting heads with Ecto for various reasons – some better than others. If you are comfortable with Ecto, I’d say go with Absinthe.

The holy grail is an Elixir graphql binding package. A graphql binding introspects a schema and generates operations based on that schema. For instance, on Node Prisma has a prisma-binding package. You give the Prisma endpoint to the binding package, and then you have an object with graphql functions, e.g.

Prisma generates

type Posts(where: PostWhereInput, orderBy: PostOrderByInput ...) {
  ...
}
input PostWhereInput {
   ...
   title: String!
   title_contains: String!
   title_starts_with: String!
   title_in: [String!]
   ...
   likes_gte: Int
   likes_lte: Int
  ...
   
}

And then in your resolver…

const result = await db.query.posts({ where: { comments: { text_contains: "Elixir" } } })

I’m developing with Node/Prisma now, but I look forward to a GraphQL binding package for Elixir and an SDL types importing mechanism, if one doesn’t already exist. (Making either are way above my pay grade to develop!)

Hopefully that helps!

6 Likes

I’m late to the party here but was messing around with prisma the other day. Hadn’t heard of it until recently (I don’t code much anymore but listen to podcasts and the co-founder of prisma has been on the podcast circuit as of late). After playing around with it for awhile it left me wondering what advantages a node + prisma app provides over my straight elixir app built with absinthe? I like having full control over migrations and it’s not very tedious to write a migration so I don’t see any big wins there (not to mention phoenix generates the migration for you most of the time). The graphiql-like data viewer is cool but it’s nothing compared to using a database tool like DataGrip. It seems like Prisma basically is an alternative to Ecto with limited database support. I really wanted to like it (and I do think it’s cool) but I didn’t find it to provide a speed advantage, or any advantages, over an elixir app with absinthe. You work with both though so maybe you can tell me what I’m missing?

1 Like

Hey Ryan, good to hear from you! I wondered what you were up to.

As I mentioned, if you like Ecto / Postgres, I would use Absinthe. I don’t. But obviously we all have our own preferences, neither right nor wrong.

What you’re missing will be largely subjective arguments. Here are mine.

  1. GraphQL all the way down. There are a lot of context shifts when running full stack in React/Apollo/Elixir/Absinthe/Ecto/Postgres. One is not like the other. I find it difficult to leave the world of arrays and objects and think in structs, lists, linked lists, etc. The same is true for me with GraphQL to SQL. Moving from the nested tree data, JSON like structure of GraphQL into Ecto configs with Elixir data structures and possibly into SQL statements, complete with Postgres table modeling is a lot of overhead.

Prisma prevents that shift. My client sends a GraphQL query. My server receives a GraphQL query and schema stitches Prisma with its own GraphQL query. Then when I need to change the data model, I update the SDL (schema definition language) types, tell Prisma to migrate the database, and it’s done. I’m not thinking SQL or Ecto (or Sequalize, Node’s ORM counterpart). And I don’t want to design by SQL schema. I want to design my GraphQL schema and let someone else translate that to performant SQL.

  1. GraphQL boilerplate at the ready. When Prisma updates its data model, it provides all of the CRUD boilerplate. But even better, it also includes GraphQL’s more advanced features in a performant package like connections (GraphQL’s/Relay’s term for pagination), subscriptions, filtering, aggregation, etc. Dataloader patterns are largely handled.

  2. You can bring all of your tools to bear. GraphiQL / GraphQL Playground are meant to introspect and test your server, not necessarily view your data. You have a real database backing the data which can be interrogated with tools like DataGrip.

  3. Multiple databases. Prisma isn’t the first to attempt a db abstraction layer for multiple dbs (looking at you Ecto). Some found limited success, but I think that we can all agree they’re largely failures. I think Prisma has a real chance to make it happen because GraphQL is the right data language and they don’t plan to leverage all features on all databases.

They currently support MySQL/Aurora and Postgres. Coming soon with Elasticsearch and Mongo. You’ll soon be able to move between main storage databases like Postgres and Mongo while leveraging specialty databases like Elasticsearch and Cassandra from the same query language.

I briefly spoke to Johannes, the founder of Prisma, about an Elixir binding package. A GraphQL binding stitches GraphQL servers together by introspecting the schema and providing an object (in Node, anyway) with all of the server’s methods and available data. He’s very interested in Elixir and bringing Prisma, but I don’t have the time and it’s probably above my pay grade. And it’s probably too much work until Absinthe supports SDL. To anyone who might be interested, the Prisma team is really talented and I’m sure would be of tremendous help!

Did any of that make sense?

4 Likes

Well, I’m the one that started this thread. When I did, I was a complete novice regarding GraphQL, prisma and Absinthe. After my initial post, I gave a decent effort trying to implement a graphql server using Absinthe. Some time passed and then I revisited using prisma. With several days effort I’ve made a lot of progress implementing my server and gaining a fair understanding of prisma. On both counts I have a ways to go.

Just today, I thought I would revisit this thread to get a better appreciation of everyone’s comments. Your comments, LawJolla, are very insightful and are consistent with my experience. Off the top, one thing that I might add is that I found all the prisma documentation to be very, very helpful.

3 Likes