Serializers in Rails
The web is built of nothing but data, and its packaging and transportation are crucial to the operation of such global networks. Serialization is a process of transforming data structures into format that can be stored, transmitted and reconstructed later.
While there are many different data-interchange formats such as MongoDb, Protobuf and YAML, the most popular and exclusively supported by REST APIs are JSON and XML. When using Rails as an API, information is wrapped up in JSON and sent to the frontend to be rendered, and reversely, data inputted in the front is converted and transported to backend to be handled and stored. By using a serializer, we can control how these information are structured, what to be sent to the browser for clients to use, and what to leave behind for record purposes.
Rails has a dedicated serializer called ActiveModel Serializers. While there are many others to choose from, this particular one is very straightforward and easy to use, with user-friendly ActiveRecord like macros to make rendering models’ data in JSON a breeze.
For a many to many relationship between a model User and a model Toy with their joiner model Toybox: a user can have many toyboxes, a toy can have many toyboxes while a toybox belongs to a user and a toy. When viewing a user’s information without filtering these data through a serializer, we might be sending to the frontend unnecessary values such as “created_at” and “updated_at”.
With the help of a serializer, we can decide what attributes of the User class to be deployed to the browser.
The attributes allowed to pass through are :id, :username and :age, nothing more.
On top of that, a good use of serializer is to include with a class information about its dependencies. A user has many toyboxes, so why not include that data along with, instead of having to make a separate request for those?
By including the model’s ActiveRecord macro demonstrating its relationship with the joiner model, our data for the user has been expanded to include their toyboxes as well.
As you might notice, the toys inside of our toyboxes are there because a given toybox belongs to a toy. Therefore, with a simple belongs_to macro inside of the Toybox serializer, we made sure to include the toybox with the toy that it belongs to in there as well.
We have decided to include in the data accessible by the frontend the timestamp at which a toy has been created. However, instead of a very non-human friendly format, we have been able to convert this created_at timestamp into a different attribute:
Where did that nice_timestamp come from? It turns out, by writing a custom method inside of the Toy model, converting the rather homely created_at timestamp into a stringified version that us human prefer, we can deploy it as an attribute to be sent out along with other data.
Without serializing our data, all of this would have been a multiple requests process just to obtain information about a user. The importance of serialization magnifies with the scope of our app. The more expansive our application is, the more crucial it is to fine tune and deploy the right information back and forth between browser and server, and server to server.
Source:
