Grape VS Blueprinter

Grape’s support extends to standard conventions, multiple format support, content negotiation, versioning, etc. The complete guide to Grape to develop REST-APIs, test the API and analyze the performance metrics is available on its official GitHub page.

Grape (ruby-grape.org)

I'm very ambivalent about Grape, but this very much reminds me of something I do really like about it: the param validation. https://github.com/ruby-grape/grape#parameters

I am currently working on developing and api using grape and devise jwt for user user authentication.

Your RN app will be making http requests to your server, so it doesn't really matter what backend language/framework you use. If your React work was also utilizing http requests to fetch data, then there shouldn't be much of a difference. If your backend is a simple JSON api, checkout Grape. You can tack it on to any existing Rails app.

I've benchmarked Grape with YJIT and without it (if want to see the code, visit repo)

Grape is a REST-like microframework written in Ruby programming language. Grape is also considered among the best ruby frameworks and can be used to run on top of Rack or can be used to complement the existing web application frameworks such as Sinatra or Rails. The latter can be done through the DSL-based REST-API for communication. The Grape ruby web framework facilitates efficient and meaningful APIs working in the web application domain.

Take a look at Grape - https://github.com/ruby-grape/grape

I love the Grape gem for building APIs - might be worth considering if you are building something new: https://github.com/ruby-grape/grape

Grape is a REST-like API framework for Ruby. It’s designed to run on Rack or complement existing web application frameworks such as Rails and Sinatra by providing a simple DSL to easily develop RESTful APIs. 9,200 stars by now

Blueprinter is something we use on a project, it's also having difficulty staying alive, but right now there is active development here, a fork from the original blueprinted gem.

Beware of this

Serializer: procore/blueprinter: Simple, Fast, and Declarative Serialization Library for Ruby

Today I thought I'd run through a few of the powerful things that the ActiveModel::Serializer gem brings to the table when used in a Ruby on Rails application. Sure, there are faster alternatives, but AMS is the first one I learned how to use, and thus it holds a special place in my heart. Quick question before we dive too much deeper, though...

Blueprint

Just an FYI: While I agree that the blueprinter gem is awesome, there are currently no active maintainers: https://github.com/procore/blueprinter/issues/288

In a happy coincidence, we're knee-deep in the middle of a migration of our serialisers to use Blueprinter instead of AMS. One benefit, in this case, is that it lets you explicitly set what generator you're using, like so:

What made me think about this is that I'm using (maybe in the wrong way) some gems like Blueprinter and Amoeba.

I've been using Blueprinter so far, and it has been working great, but I'd like to ditch it if I can.

We use it extensively for one project. The only annoying bit involves defining the response json-schema. Luckily we are using a gem called blueprinter for JSON serialization, so we added a bunch of overrides that store metadata, so we can generate the json-schema with meta programming. You might need to find a library that would help you write the schemas fluently [1] / [2] to make it easier to define them.