Fast JSON API VS graphql

NASA uses Ruby on Rails ... Netflix originally had one of the best JSON API serializers (before changing maintainers).

There is a to_json method and recent benchmarks I found are placing a few ms above fast_jsonapi (which is no longer maintained) and slightly faster that jsonapi-serializer (which is supposed to replace fast_jsonapi according to their website).

Netflix has definitively had some Ruby in the past as they have the (now unmaintained) https://github.com/Netflix/fast_jsonapi All their ruby repos seem to be abandoned though, so assume there's not much going on there with Ruby currently.

Last week, I covered tricks and tips with handling forms and updating state, as well as sending the data through fetch requests to the backend. Since then, I have been working endlessly on fetching data from the backend, which included building relationships between my various models and sending the data through a Json Serializer made by Netflix, Fast_JSONAPI Serializer (now just JSONAPI Serializer). I learned some new things while working with the serializer and felt I could impart my wisdom this week.

After googling and reading some articles, I found that there are a lot of blogs related to Fast JSON API which is now deprecated and kind of replaced by JSON:API Serializer. These gems are following JSON:API specification and force our API response to meet this specification standard.

My memory is fuzzy, but...

1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading).

2. no support for CDNs (I think newer rails versions added support)

3. blobs and attachments were unnecessary abstractions.

3a. Querying was annoying and easy to add n+1 queries.

3b. Images are moderated and it was unclear where to put the moderation metadata (on blobs? attachments? create a new table? why so many tables?). Accessing the data was annoying (you need extra joins).

4. GraphQL gem didn't support it: https://github.com/rmosolgo/graphql-ruby/issues/1777

In our Rails application, we use the popular graphql Ruby gem to resolve GraphQL queries. When used naively, it essentially resolves queries as a depth-first tree traversal, which leads to the N+1 problem in GraphQL.

If you're comfortable on the react/client side with graphql, I'd highly recommend plugging in https://graphql-ruby.org/

We use GraphQL, and Ruby GraphQL doesn't allow you to stream the result, it buffers it before sending back the request and there are no alternative. See my issue https://github.com/rmosolgo/graphql-ruby/issues/3969 -- Sadly there is only one library for GraphQL in Ruby.

graphql-ruby is a Ruby gem that implements the GraphQL specification and functionalities.

The next step is to add the GraphQL gem to our Gemfile; you can visit its page, graphql-ruby, for more details; now, open your Gemfile and add this line:

If you do go the API route though, strongly consider using GraphQL with the (graphql-ruby)[https://graphql-ruby.org/] gem.

GraphQL saves you time designing versioned REST endpoints. It self documents. Documentation isn't optional for serious web development so this is a huge win. The rails gems have gotten really good at picking up associations as well since I looked into a couple years ago. https://graphql-ruby.org

When it comes to implementing a GraphQL server in Rails, one can use the excellent GraphQL Ruby gem.