This is counter-intuitive, but science says that having too many choices will leave you miserable. Thank God it’s not the case when you need to choose GraphQL library for your ruby project — you had to choose graphql-ruby, because there was no other option before. But hey, I have a good news: now there is the second option — graphql_rails.
graphql-ruby is very low level gem and I wanted to level it up by adding additional abstraction layers. So step by step I ended up with Ruby on Rails architecture oriented gem called graphql_rails. In most cases it’s not even an alternative, but an extension since it’s built on top of graphql-ruby. This means that you can still use most of graphql-ruby features.
The Beast: GraphQL-Ruby
You will be blown away by it’s power and abilities: queries, mutations, subscriptions, input types, enums, custom types… List is endless. Possibilities are endless, too.
It’s a powerful gem which allows you to do all the fancy GraphQL things. You can build whatever and any way you like by using its relatively simple blocks. If you are obsessed with controlling everything then graphql-ruby is a way to go.
In graphql-ruby you always start with schema in which you declare your root types:
Later you need to describe type fields, which looks like this:
So, as you may have noticed, flow is quite simple:
But for big power you have to pay the price. It looks easy as long as you do not need any fancy stuff, like different strategies for authenticating user, handling permissions, reusing some code from Ruby on Rails, logging and etc.
All the freedom and power given by graphql-ruby slows your development down. You need to write a lot of boilerplate , you have to think in advance about structure of your GraphQL code, otherwise you will end up with chaotic code which is extremely difficult to test. It’s not that fun when you just need to make your GraphQL endpoint rollin’.
The Beauty: GraphQL Rails
Short. Clear. Simple… Beautiful!
If you can use those words to describe code that you have to deal with each day, then you are living a happy life.
People love ruby because of it’s beauty and expressiveness. Those people will love graphql_rails too. It has same methods and same behavior as Ruby on Rails, so it will allow you to have consistent code everywhere. Its MVC-like architecture lets you reuse same tools which you are familiar with, so you will end up with more DRY code.
In graphql_rails everything starts with router:
Same as in Ruby on Rails, you describe your resources which under the hood creates endpoints to CRUD actions. Then you create controller for each resource with those CRUD actions:
On daily basis you will not notice any difference between standard Ruby on Rails controller and graphql_rails controller which is a good indicator that your code is consistent and well structured.
With graphql_rails you don’t need to create type classes, you just need to update your existing models. So let’s add type definitions into your existing model:
The beauty of graphql_rails is its similarity with other parts of Ruby on Rails. Having MVC architecture both on Ruby on Rails and GraphQL part is a big win. This allows you to reuse existing code and work with GraphQL as an extension of Ruby on Rails without introducing new unnecessary patterns or duplicating code.
So what to use for your next project?
Spoiler alert! It depends. What a surprise, huh?! My rule of thumb is this: