graphql-batch VS Interactor

Interesting, I've just been researching Dataloader implementations for Ruby and have between trying to decide between GraphQL::Dataloader, graphql-batch and BatchLoader. I'll give this a look as well. Can you also make API calls inside the loaders?

This is mainly addressed in the last thing but we cache pretty heavily on our REST APIs and for GraphQL we use the graphql-batch gem pretty heavily. Those two things can go a long way. Make sure you're using an APM like Scout to keep an eye on things and then debug the outliers.

I see many senior Ruby developers around me going away from that magicness (like all the validations and callbacks) to move away from fat models, using libs like https://github.com/collectiveidea/interactor and have their own control.

The Interactor and ActiveInteraction gems are both great libraries for implementing this pattern.

I've used https://github.com/collectiveidea/interactor on some apps with a lot of success.

Have a look at https://github.com/collectiveidea/interactor, they give you a new pattern that would allow you to think more in POROs and one class per responsibility. Active Record puts your head in a box where every model has to have a database table. Try to break out of that

We don't do too many things The Rails Way™ anymore. We tend to use the Interactor pattern using the aptly named gem. We use Wisper to broadcast events instead of using AR callbacks. We use Pusher for websockets because we broadcast millions of events per day and ActionCable just can't keep up.

In this blog, we are going to look at Interactor using interactor gem. It is quite easy to integrate into an existing project.

There are lots of different libraries that you can use to organize/structure/enhance your "service objects", or you can just use plain old Ruby classes (as in the example above).

In the past I've used (and loved) https://github.com/collectiveidea/interactor