DEV Community: Bogdanov Anton

Prevent over-fetching data for REST API in Ruby on Rails

Bogdanov Anton — Tue, 12 Mar 2024 07:26:49 +0000

One of the main features of GrahpQL compared to the REST api - GraphQL APIs let clients query the exact data they need, while REST APIs just returns all data described in serializers.

While I prefer using REST API for my rails apps I tried to find solution for optimizing responses. I made some attempts with multiple serializers for different controllers and for the same models, but it leds to mess.

With using jsonapi-serializer I found solution.

Attributes of serializer can be optional with if and proc

class UserSerializer < ApplicationSerializer
  attribute :confirmed, if: proc { |_, params| required_field?(params, 'confirmed') }, &:confirmed?
  attribute :banned, if: proc { |_, params| required_field?(params, 'banned') }, &:banned?
end

During serialization such attributes will be or will not be serialized based on provided params.

Attribute will be serialized if it presents in include_fields or does not present in exclude_fields.

class ApplicationSerializer
  def self.required_field?(params, field_name)
    params[:include_fields]&.include?(field_name) || params[:exclude_fields]&.exclude?(field_name)
  end
end

And this is how part in controllers works

SERIALIZER_FIELDS = %w[confirmed banned].freeze
def index
  render json: {
    user: UserSerializer.new(
      current_user, params: serializer_fields(UserSerializer, SERIALIZER_FIELDS)
    ).serializable_hash
  }, status: :ok
end

Method serializer_fields generates hash with include/exclude attributes based on params and compares it with available attributes from serializer. Later that hash is used in serializer.

def serializer_fields(serializer_class, default_include_fields=[])
  @serializer_attributes = serializer_class.attributes_to_serialize.keys.map(&:to_s)
  return {} if response_include_fields.any? && response_exclude_fields.any?
  return { include_fields: response_include_fields } if response_include_fields.any?
  return { exclude_fields: response_exclude_fields } if response_exclude_fields.any?
  return { include_fields: default_include_fields } if default_include_fields.any?

  {}
end

def response_include_fields
  @response_include_fields ||= params[:response_include_fields]&.split(',').to_a & @serializer_attributes
end

def response_exclude_fields
  @response_exclude_fields ||= params[:response_exclude_fields]&.split(',').to_a & @serializer_attributes
end

This approach allows to achieve:

preventing over-fetching data by REST API,
tracking required attributes for responses (maybe some of them are not used at all),
usually controller could have some .includes for optimization, and based on required attributes such optimizations/additional requests to DB can be skipped.

I hope this approach will help somebody with REST API optimization their Rails apps.

Better UI for Que background jobs adapter

Bogdanov Anton — Sun, 03 Mar 2024 05:39:43 +0000

Good day, Rails devs!

In my rails apps for background jobs I use mostly Que adapter, and for checking jobs status through UI only Que::Web was available.

Some time ago I got difficults with updating apps to rack 3 because of Que::Web's Sinatra, and decided to make own UI as simple Rails engine. So let me introduce Que::View - new UI interface for Que jobs.

No more redundant dependencies, much freshier gem (Que::Web was not updated last 2 years). I hope it would be useful for those who use Que adapter.

Get the PR statistics from Github with PullKeeper

Bogdanov Anton — Fri, 01 Mar 2024 10:14:04 +0000

In the process of growing a development team, sometimes it becomes necessary to have some way to calculate the effectiveness of developers, compare them with each other, motivate them, encourage and punish (maybe, sometimes).

And if the quality of the code is a rather difficult thing to calculate, then the quality and speed of reviewing of pull requests can be calculated. In our company first we started to use a pull request stats package that integrates with github actions and publishes review statistics directly in pull requests. But we had some issues and incorrect calculations.

We thought that those library technically can not meet our needs, then why not make our own web service, for example with Ruby on Rails, a couple of weeks of work and we had the PullKeeper — open source application for getting relevant statistics about PRs, reviewers and comments. Now all statistics can be collected in one place, conveniently divided into statistics for individual repositories and for the whole company.

Аfter 1 year of improving PullKeeper right now tracks 12 developer metrics and 10 repository metrics, so team leads and project managers can very accurate measure their teams in reviewing PRs, find weak places, maybe review process spends huge amount of time (PRs have low code quality), or testing is long process - so features are delivered not so fast to production.

Main feature of PullKeeper that allows accurately calculate review time is excluding not-working time of developers (in compare with other solutions), by default night time is already excluded from calculations, and in addition there is option to specify company's working time.

Additional features:

all statistics refreshes automatically, no need to wait new open PR for refreshing it,
for each company you can specify non-working hours (only working time can be taken into account when calculating the time spent on review),
it works with Github and Gitlab,
you can choose statistics to display in the tables,
you can also choose to render statistics of changes in efficiency compared to the previous period,
if developer login into the application he will receive read access to all repositories and companies where he has insights,
sending statistics to Slack/Discord/Telegram channels, so you don’t need to log into the application to check statistics,
achievements system for representing and comparing developer success.

The application is open source, you can check it, leave feedback, describe bugs or ask to integrate new features.

A few companies started to use it, if you find PullKeeper useful too - it will make me a little happier.