{"id":3497,"date":"2022-01-13T12:34:44","date_gmt":"2022-01-13T12:34:44","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/polymorphism-in-ruby-and-graphql\/"},"modified":"2026-04-28T14:06:49","modified_gmt":"2026-04-28T14:06:49","slug":"polymorfismus-v-jazycich-ruby-a-graphql","status":"publish","type":"post","link":"https:\/\/thecodest.co\/cs\/blog\/polymorphism-in-ruby-and-graphql\/","title":{"rendered":"Polymorfismus v jazyce Ruby a GraphQL"},"content":{"rendered":"\n

Polymorphism<\/h2>\n\n\n\n

Polymorphism<\/strong> is a key component of object-oriented programming<\/strong>. To simplify things, it is based on the fact that objects of different classes have access to the same interface, which means that we can expect from each of them the same functionality but not necessarily implemented in the same way. In Ruby<\/a> developers<\/strong> can obtain polymorphism<\/strong> in three ways:<\/p>\n\n\n\n

Inheritance<\/h3>\n\n\n\n

Inheritance<\/strong> consists in creating a parent class and child classes (i.e., inheriting from the parent class). Subclasses receive the functionality of the parent class and also allow you to change and add a functionality.<\/p>\n\n\n\n

Example:<\/p>\n\n\n\n

class Document\n  attr_reader :name\nend\n\nclass PDFDocument < Document\n  def extension\n    :pdf\n  end\nend\n\nclass ODTDocument < Document\n  def extension\n    :odt\n  end\nend<\/code><\/pre>\n\n\n\n
Modules<\/h3>\n\n\n\n
Modules in Ruby<\/strong> have many uses. One of them is mixins (read more about mixins in The Ultimate Breakdown: Ruby vs. Python<\/a>). Mixins in Ruby can be used similarly to interfaces in other programming languages<\/a> (e.g., in Java<\/a>), for instance, you can define in them methods common to objects that will contain a given mixin. It is a good practice to include read-only methods in modules, so methods that will not modify the state of this object.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
module Taxable\n  def tax\n\n     price * 0.23\n  end\nend\n\nclass Car\n  include Taxable\n attr_reader :price\nend\n\nclass Book\n  include Taxable\n\n attr_reader :price\nend<\/code><\/pre>\n\n\n\n
Duck typing<\/h3>\n\n\n\n
This is one of the key features of dynamically typed languages. The name comes from the famous test if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck. The programmer<\/strong> does not have to be interested to which class the given object belongs. What is important are the methods that can be called on this object.<\/p>\n\n\n\n
Using the classes defined in the example above:<\/p>\n\n\n\n
class Car\n  attr_reader :price\n\n def initialize(price)\n    @price = price\n   end\nend\n\nclass Book\n  attr_reader :price\n\n def initialize(price)\n    @price = price\n  end\nend\n\ncar = Car.new(20.0)\nbook = Book.new(10.0)\n\n[car, book].map(&:price<\/code><\/pre>\n\n\n\n
GrapQL<\/h3>\n\n\n\n
GraphQL<\/strong> is a relatively new query language for APIs. Its advantages include the fact that it has a very simple syntax and, in addition, the client decides what exactly they want to get as each customer gets exactly what they want and nothing else.<\/p>\n\n\n\n
Sample query in GraphQL<\/strong>:<\/p>\n\n\n\n
{\n  allUsers {\n     users {\n        id\n        login\n        email\n\n       }\n     }\n   }<\/code><\/pre>\n\n\n\n
Sample response:<\/p>\n\n\n\n
{\n  \"allUsers\": {\n    \"users\": [\n     {\n        \"id\": 1,\n        \"login\": \"user1\",\n        \"email\": \"user1@te.st\"\n      },\n      {\n        \"id\": 2,\n        \"login\": \"user2\",\n        \"email\": \"user2@te.st\"\n      },\n    ]\n  }\n}<\/code><\/pre>\n\n\n\n
This is probably all we need to know at the moment. So, let’s get to the point.<\/p>\n\n\n\n
Presentation of the problem<\/h2>\n\n\n\n
To best understand the problem and its solution, let’s create an example. It would be good if the example was both original and fairly down-to-earth. One that each of us<\/a> can encounter someday. How about… animals? Yes! Great idea!<\/p>\n\n\n\n
\"ruby<\/figure>\n\n\n\n
Suppose we have a backend application written in Ruby on Rails<\/a><\/strong>. It is already adapted to handle the above scheme. Let’s also assume that we already have GraphQL<\/strong> configured. We want to enable the client to make an inquiry within the following structure:<\/p>\n\n\n\n
{\n allZoos : {\n    zoo: {\n      name\n      city\n      animals: {\n        ...\n      }\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
What should be put instead of the three dots in order to obtain the missing information \u2013 we will find out later.<\/p>\n\n\n\n
Implementation<\/h2>\n\n\n\n
Below I will present the steps needed to achieve the goal.<\/p>\n\n\n\n
Adding a query to QueryType<\/h3>\n\n\n\n
First, you need to define what exactly the query allZoos means. To do this, we need to visit the fileapp\/graphql\/types\/query_type.rb<\/code> and define the query:<\/p>\n\n\n\n
   module Types\n      class QueryType < Types::BaseObject\n       field :all_zoos, [Types::ZooType], null: false\n\n       def all_zoos\n          Zoo.all\n       end\n    end\n end<\/code><\/pre>\n\n\n\n
The query is already defined. Now it’s time to define the return types.<\/p>\n\n\n\n
Definition of types<\/h3>\n\n\n\n
The first type required will be ZooType. Let’s define it in the file app\/graphql\/types\/ zoo_type.rb<\/code>:<\/p>\n\n\n\n
module Types\n  class ZooType < Types::BaseObject\n    field :name, String, null: false\n    field :city, String, null: false\n    field :animals, [Types::AnimalType], null: false\n  end\nend<\/code><\/pre>\n\n\n\n
Now it’s time to define the type AnimalType:<\/p>\n\n\n\n
module Types\n  class AnimalType < Types::BaseUnion\n   possible_types ElephantType, CatType, DogType\n\n     def self.resolve_type(obj, ctx)\n       if obj.is_a?(Elephant)\n          ElephantType\n       elsif obj.is_a?(Cat)\n         CatType\n       elsif obj.is_a?(Dog)\n        DogType\n      end\n    end\n  end\nend<\/code><\/pre>\n\n\n\n
What do we see in the code<\/a> above?<\/p>\n\n\n\n
    \n
  1. The AnimalType inherits from Types::BaseUnion<\/code>.<\/li>\n\n\n\n
  2. We have to list all types that can make up a given union.
    3.We override the function self.resolve_object(obj, ctx),<\/code>which must return the type of a given object.<\/li>\n<\/ol>\n\n\n\n
    The next step is to define the types of animals. However, we know that some fields are common to all animals. Let’s include them in type AnimalInterface:<\/p>\n\n\n\n
    module Types\n  module AnimalInterface\n    include Types::BaseInterface\n\n    field :name, String, null: false\n    field :age, Integer, null: false\n  end\nend<\/code><\/pre>\n\n\n\n
    Having this interface, we can proceed to define the types of specific animals:<\/p>\n\n\n\n
    module Types\n  class ElephantType < Types::BaseObject\n    implements Types::AnimalInterface\n\n    field :trunk_length, Float, null: false\n  end\nend\n\nmodule Types\n  class CatType < Types::BaseObject\n   implements Types::AnimalInterface\n\n   field :hair_type, String, null: false\n  end\nend\n\nmodule Types\n  class DogType < Types::BaseObject\n    implements Types::AnimalInterface\n\n     field :breed, String, null: false\n  end\nend<\/code><\/pre>\n\n\n\n
    That’s it! Ready! One last question: how can we use what we have done from the client\u2019s side?<\/p>\n\n\n\n
    Building the query<\/h3>\n\n\n\n
    {\n allZoos : {\n   zoo: {\n      name\n      city\n      animals: {\n        __typename\n\n        ... on ElephantType {\n          name\n          age\n          trunkLength\n        }\n\n         ... on CatType {\n          name\n          age\n          hairType\n         }\n         ... on DogType {\n          name\n          age\n          breed\n         }\n       }\n     }\n   }\n }<\/code><\/pre>\n\n\n\n
    We can use an additional __typename field here, which will return the exact type of a given element (e.g., CatType). What will a sample answer look like?<\/p>\n\n\n\n
    {\n  \"allZoos\": [\n\n   {\n      \"name\": \"Natura Artis Magistra\",\n      \"city\": \"Amsterdam\",\n      \"animals\": [\n        {\n          \"__typename\": \"ElephantType\"\n          \"name\": \"Franco\",\n          \"age\": 28,\n          \"trunkLength\": 9.27\n         },\n         {\n         \"__typename\": \"DogType\"\n         \"name\": \"Jack\",\n         \"age\": 9,\n         \"breed\": \"Jack Russell Terrier\"\n        },\n      ]\n    }\n  ]\n} <\/code><\/pre>\n\n\n\n
    Analysis<\/h3>\n\n\n\n
    One drawback of this approach is apparent. In the query, we must enter the name and age in each type, even though we know that all animals have these fields. This is not bothersome when the collection contains completely different objects. In this case, however, the animals share almost all fields. Can it be improved somehow?<\/p>\n\n\n\n
    Of course! We make the first change in the file app\/graphql\/types\/zoo_type.rb<\/code>:<\/p>\n\n\n\n
    module Types\n  class ZooType < Types::BaseObject\n    field :name, String, null: false\n    field :city, String, null: false\n    field :animals, [Types::AnimalInterface], null: false\n  end\nend<\/code><\/pre>\n\n\n\n
    We no longer need the union we have defined before. We change Types::AnimalType<\/code> to Types::AnimalInterface<\/code>.<\/p>\n\n\n\n
    The next step is to add a function that returns a type from Types :: AnimalInterface<\/code> and also add a list of orphan_types, so types that are never directly used:<\/p>\n\n\n\n
    module Types\n  module AnimalInterface\n    include Types::BaseInterface\n\n   field :name, String, null: false\n   field :age, Integer, null: false\n\n   definition_methods do\n      def resolve_type(obj, ctx)\n        if obj.is_a?(Elephant)\n          ElephantType\n        elsif obj.is_a?(Cat)\n          CatType\n        elsif obj.is_a?(Dog)\n          DogType\n        end\n      end\n    end\n    orphan_types Types::ElephantType, Types::CatType, Types::DogType\n  end\nend<\/code><\/pre>\n\n\n\n
    Thanks to this simple procedure, the query has a less complex form:<\/p>\n\n\n\n
    {\n  allZoos : {\n   zoo: {\n      name\n      city\n      animals: {\n        __typename\n        name\n        age\n\n       ... on ElephantType {\n          trunkLength\n\n       }\n       ... on CatType {\n          hairType\n\n       }\n       ... on DogType {\n          breed\n\n        }\n      }\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
    Summary<\/h2>\n\n\n\n
    GraphQL<\/strong> is a really great solution. If you don’t know it yet, try it. Trust me, it’s worth it. It does a great job in solving problems appearing in, for example, REST APIs. As I showed above, polymorphism<\/strong> is not a real obstacle for it. I presented two methods to tackle it.
    Reminder:<\/p>\n\n\n\n