![](\"/img/2020-08-21-mirage-serializers-setup.png\")
MirageJS is one of the pioneers in enabling frontend developers to use mocks systematically for their tests and development. It was originally built for Ember.js in 2015, but due to its popularity the maintainers created a standalone version compatible with any javascript framework.
\nMirage introduces itself as a mocking library, but at Frontside we don't think that's a good enough term to refer to its extensive power. If your application uses a RESTful API (an adapter for GraphQL is on the way), Mirage is a great choice to simulate your backend with high-fidelity outputs. We've used Mirage in several projects to enable frontend developers to keep advancing the UI while the backend is not yet ready. Its flexibility also makes it a perfect test companion compatible with many tools out there, including Cypress.
\nA key element of Mirage that enables it to generate realistic responses lies on its serializer layer. The serializer takes the data stored in Mirage's seeded database and outputs it in the format that you configure for it. For an effective simulation strategy, you want that output format to match exactly your backend API specifications.
\nIn this article, we'll explore the four serializers available on Mirage by default. Choosing which one is the right one for you depends on your API formats. There might be a serializer that works with your backend right out of the box or you may have to customize it from a base. After outlining how the serializer layer works in Mirage, we'll dive into the specifics of each one.
\n\nUnderstanding how Mirage’s various serializers work begins with reviewing how data flows thought Mirage. At the most basic level, Mirage allows you to create mocks in a traditional way, returning hand-crafted objects:
\nthis.get(\"/blog-posts\", () => {\n return [\n { id: \"1\", title: \"Beyond mocking\" },\n { id: \"2\", title: \"A lesson about Interactors\" },\n { id: \"3\", title: \"Github Actions: all about pull_request\" },\n ];\n})However, hand-crafted anything is not a scalable solution, and these sorts of objects become difficult to maintain when your data relies on relationships.
\nInstead, we recommend taking advantage of Mirage modeling and ORM capabilities so you can shape your backend in Mirage and seed it with generated data. As the snipped code below illustrates, you can use the seeded models of the database directly from your route handle:
\nthis.get(\"/users\", (schema, request) => {\n return schema.users.all()\n})In this case you don't have to manually deal with IDs, formats, or the concrete user records. Instead, you use a schema query that will bring records (based on models and factories) from Mirage's database and output the format that your backend uses.
\nIn order to do that, you have to set up models, factories, and serializers in Mirage. Models deal with the relationship between records, factories generate sample data for the records' attributes, and serializers format how the records will be mapped in a JSON response. The following diagram illustrates how these pieces come together to enable you to query records in your Mirage route handles:
\n
The role of the serializer is to map the data to a JSON structure that matches your backend needs. The structure of the JSON refers to how the object keys are named and what's nested inside which keys.
\nGiven that the serializer's main purpose is to make it easy for you to have Mirage outputting realistic data for your frontend, we recommend discussing with your backend team how they plan to format the responses from their endpoints. Then you can compare those responses to what the different Mirage serializers offer and choose the closest one, customizing it if necessary.
\nThe job of a serializer is to provide a format that represents the attributes and relationships of the records stored in Mirage’s database. To illustrate how the different serialiser options work, in this section we’ll describe a hypothetical set up. It’s worth noting at the outset that in Mirage models only describe relationships, not attributes; that means attributes can be defined arbitrarily when the model is instantiated in a factory.
\nIn the code below we’ll use three models to describe the relationships among our data:
\nmodels: {\n author: Model.extend({\n\tblogPosts: hasMany(),\n }),\n\n blogPost: Model.extend({ \n\tauthor: belongsTo(),\n\tpost_blogComments: hasMany()\n }),\n\n post_blogComment: Model.extend({\n\tblogPost: belongsTo()\n })\n}Notice the inconsistencies in case and separators in the names for the model’s fields. We've used arbitrary casing so the effect of the serializers described below is more apparent.
\nNow for the factories, we’ll set them as described below. As we mentioned earlier, it’s in this part where the attributes for our records are declared:
\nfactories: {\n author: Factory.extend({\n author_emailAddress: () => faker.internet.email()\n }),\n blogPost: Factory.extend({\n blogPost_title: () => faker.random.words(3)\n })\n post_blogComment: Factory.extend({\n comment_paragraph: () => faker.random.words(6)\n }),\n}}\nAgain, to highlight the effects of serializers on the attribute names, notice that in the code above the casing for each attribute is mixed. You can see we're using a library called faker to generate random data to populate the models attributes.
To make the outputs comparable across serializers, the example responses that we provide are the result of fetching a request for all blogPosts:
schema.blogPosts.all( )Before getting into the specific serializers, let’s address first a peculiarity about attributes that all Mirage serializers share. As it turns out, Mirage doesn’t serialize all the attributes of a response evenly.
\nWhen we fetch all the blog posts with schema.blogPosts.all( ) we'll get all the records for blogs posts. If we configure the serializer to include relationships, we can expect the authors and comments from such blog posts too. The following diagram illustrates the relationships between blog posts, authors, and comments.
![](\"/img/2020-08-21-mirage-relationships.png\")
Because we’re using schema.blogPosts.all( ) to get these blog posts, we’ll say that blog posts are the queried records. As mentioned, included in that response we’d have the author of the blog post (through belongsTo). Additionally, we’ll get the blog post comments (through hasMany).
Serialization on queried records: attribute names are transformed
\nSerializers will only transform the attribute names of the queried records. The transformations applied vary from serializer to serializer; you’ll find the specifics in the sections below.
\nRecords from belongsTo: attribute names are not transformed
\nCounterintuitively, the serializers in Mirage will not apply any transform to the attribute names of the records coming from a belongsTo relationship. This means that the inconsistent attribute name we included in our authors factory will remain as it was declared, author_emailAddress no matter which serializer you use.
Records from hasMany: attributes are not included
\nPerhaps to avoid loading large amounts of data, Mirage does not include the attributes of any record that has been loaded due to a hasMany relationship. This means that although we’ll get a list of the comments associated to the blog post we queried, we will not be able to get any of their attributes.
\nThis serializer follows the JSON API specification. A fetch for blogPosts with this serializer will return the following response format:
{\n \"data\": [\n {\n \"type\": \"blog-posts\",\n \"id\": \"1\",\n \"attributes\": {\n \"blog-post-title\": \"A blog post\"\n }\n \"relationships\": {...}\n },\n ...\n ],\n \"included\": [...]\n}In compliance with JSON API conventions, all field names are changed to use dashes. As you can see in the example, the names that were inconsistently cased are all dasherized now; for instance, blogPost_title becomes blog-post-title.
There are two top level keys for the JSON API response: data and included.
The main part of the response is data, an array of entries that answer to the query issued. In this case, it's providing all the blog posts available.
The other key, included will have the record information from the references related to the entries in data. By default, included is empty on Mirage.
Each record on data can have a relationships key. In our example, the blog post belongsTo an author and hasMany blog post comments. By default, the relationships are not included in Mirage by the JSON API serializer.
To include the relationships, we can configure the include option in the JSON API serializer. In that case, we'll get a relationships key inside each record from data with references to what those authors or comments are.
Below you can see how a single record looks like when the relationship references are included:
\n{\n \"type\": \"blog-posts\",\n \"id\": \"1\",\n \"attributes\": {\n \"blog-post-title\": \"A blog post\"\n },\n \"relationships\": {\n \"author\": {\n \"type\": \"authors\",\n \"id\": \"5\"\n },\n \"post-blog-comments\": {\n \"type\": \"post-blog-comments\",\n \"id\": \"5\"\n }\n }\n}Notice that in JSON API Serializer, types are all dasherized and pluralized, and that they are used in every record. For instance, a single author has a type authors.
Additionally, all the records referenced in all the relationships key will be loaded in the included key of the response.
Alternatively, we can set the alwaysIncludeLinkageData option to true on the JSON API serializer, with which we'd get the relationship information on the data records, but those related records will not be included in the include array.
Active Model is the standard format for Rails APIs responses. Chances are if you don't already know whether or not you need to use this serializer, you most likely don't need this one. But let's still have a look at how this one handles its response. We'll be evoking the same fetch as the one we used for the JSON API Serializer. This is how the response with the Active Model Serializer would look:
\n{\n \"blog_posts\": [\n {\n \"id\": \"0\",\n \"blog_post_title\": \"A blog post\",\n \"author_id\": \"...\",\n \"post_blog_comments_ids\": [...]\n }\n ]\n}The Active Model Serializer changes the caps to be under_scored no matter how the original model name was configured. As you can see in the example, the attribute names that were inconsistently cased are all under_scored now; for instance, blogPost_title becomes blog_post_title.
The Active Model Serializer presents the entity types on the top level arrays, where the type name is pluralized. Unlike the JSON API Serializer the data is not nested under data or included objects. You can think of the response having lists of records grouped by type on the top level. In this example, blog_posts is the type of the queried objects and it's at the top level.\nRelationships: _id suffixed reference (or embedded)
By default, relationships are not resolved for this serializer. However, we can configure the include option for the Active Model Serializer and then we'll receive them as references but in a different format than JSON API.
If include is configured, the records of the related fields in a relationship are also loaded at the top level of the JSON with their type names. In the target object, the reference to that related object is only an id.
The field name of the relationship will be appended _id:
{ \n \"blog_posts\": [\n {\n \"id\": \"1\",\n \"author_id\": \"5\"\n }\n ],\n \"authors\": [\n {\n \"id\": \"5\",\n \"name\": \"Mika\"\n }\n ]\n}Additionally, you can decide to configure the embed option to nest the relationship object instead of having a reference:
{ \n \"blog_posts\": [\n {\n \"id\": \"1\",\n \"author\": {\n \"id\": \"5\",\n \"name\": \"Mika\"\n }\n }\n ]\n}The Rest Serializer is almost identical to the Active Model Serializer except that it transforms names to camelCase instead of under_score. Let's look at the example output for Rest Serializer:
\n{\n \"blogPosts\": [\n {\n \"id\": \"0\",\n \"blogPostTitle\": \"A blog post\"\n \"author\": \"...\",\n \"postBlogComments\": [...]\n }\n ]\n}The Rest Serializer changes the caps to use camelCase no matter how the original attribute name was configured. As you can see in the example, the names that were inconsistently cased are all camelCased now; for instance, blogPost_title becomes blogPostTitle.
The Rest Serializer presents the entity types on the top level, in the same way Active Model Serializer does: the top level keys are pluralized camelCase types.\nRelationships: no-suffix id reference (or embedded)
\nBy default, relationships are not resolved for this serializer. However, we can configure the include option for the serializer and then we'll receive them as references.
If include is configured, the records of the related fields in a relationship are also loaded at the top level of the JSON with their type names. In the target object, the reference to that related object is only an id. The field name of the relationship will not be suffixed with anything:
{ \n \"blogPosts\": [\n {\n \"id\": \"1\",\n \"author\": \"5\"\n }\n ],\n \"authors\": [\n {\n \"id\": \"5\",\n \"name\": \"Mika\"\n }\n ]\n}Additionally, you can decide to configure the embed option to nest the relationship object instead of having a reference:
{ \n \"blogPosts\": [\n {\n \"id\": \"1\",\n \"author\": {\n \"id\": \"5\",\n \"name\": \"Mika\"\n }\n }\n ]\n}Last but not least is the barebone Serializer which MirageJS describes as basic. Its behavior is quite similar to Rest Serializer, with the only difference lying in how the relationship references are suffixed.
Let's check out the output for Serializer:
\n{\n \"blogPosts\": [\n {\n \"id\": \"1\",\n \"blogPostTitle\": \"A blog post\"\n \"authorId\": \"...\",\n \"postBlogCommentsIds\": [...],\n }\n ]\n}This serializer changes the caps to use camelCase, no matter how the original attribute name was configured. As you can see in the example, the names that were inconsistently cased are all camelCased now; for instance, blogPost_title becomes blogPostTitle.
The Serializer presents the entity types on the top level, in the same way Active Model Serializer does: the top level keys are pluralized camelCase types.\nRelationships: Id suffix reference (or embedded)
By default, relationships are not resolved for this serializer. However, we can configure the include option for this serializer and then we'll receive them as references.
If include is configured, the records of the related fields in a relationship are also loaded at the top level of the JSON response with their type names. In the target object, the reference to that related object is only an id.
The field name of the relationship will be appended Id:
{ \n \"blogPosts\": [\n {\n \"id\": \"1\",\n \"authorId\": \"5\"\n }\n ],\n \"authors\": [\n {\n \"id\": \"5\",\n \"name\": \"Mika\"\n }\n ]\n}Additionally, you can decide to configure the embed option to nest the relationship object instead of having a reference:
{ \n \"blogPosts\": [\n {\n \"id\": \"1\",\n \"author\": {\n \"id\": \"5\",\n \"name\": \"Mika\"\n }\n }\n ]\n}| \n | JSON API Serializer | \nActive Model Serializer | \nRest Serializer | \nSerializer | \n
|---|---|---|---|---|
| Response structure | \n\n Top level data and included keys.\n Every type-name is used in plural in each record.\n | \n Top level keys by pluralized type_name. | \nTop level keys by pluralized typeName | \nTop level keys by pluralized typeName | \n
| Casing transforms | \ndasherized | \nunder_score | \ncamelCase | \ncamelCase | \n
| Relationships included in response? | \nNo, unless include is configured. Option for alwaysIncludeLInkageData | \n No, unless include is configured | \n No, unless include is configured | \n No, unless include is configured | \n
| Relationship reference in record | \n\n relationships key with reference object. \n ex. | \n Name of attribute suffixed with _id ex: \"author_id\": \"5\" | \n Name of attribute with no suffic ex: \"author\": \"5\" | \n Name of attribute suffixed with Id ex: \"authorId\": \"5\" | \n