Latest blog entries

SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides


Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace


Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

Thoughts on rebar3

Thoughts on rebar3

Jun 08 2016 : Hernán Rivas Acosta

7 Heuristics for Development

What we've learned from Hernán Wilkinson at our Tech Day

May 31 2016 : Brujo Benavides

See all Inaka's blog posts >>

Introducing Dayron - The Elixir REST client you've always wanted

A photo of Flavio Granero wrote this on May 24, 2016 under announcement, crud, elixir, inaka, library, open-source, release, rest .

The Motivation

If you ever started a Phoenix Application and/or played a bit with Ecto, you should've realized how powerful the library is. With Ecto you can define Repos to access the Database, select which adapter is the best one to interface an specific DB server, define schemas, migrations, build SQL queries with a nice DSL, etc. Definitely, it's an awesome library.

Ok, but we're not here to talk about Ecto awesomeness, right? Well, kind of.

We want to share with you all the motivation behind the creation of Dayron. And that's directly connected to the fact that we love Ecto and how it lets you handle database wrappers.

Here at Inaka we now have some experience porting existent projects to Elixir, but also starting new Elixir/Phoenix applications from scratch for our clients. In one of those projects, we found a legacy API that needed to be consumed from a new Phoenix application we were just beginning to build. Let's call that new application just "Admin" from now on.

The legacy API would be rewritten soon, focusing on providing better scalability, by another development team. And, as the API team was already working on that, we couldn't ask them for new endpoints that Admin would need for sure, to have their features working.

The initial idea was to get Admin project to work just by consuming the API, which is shared between several applications, and having no direct database connection. However, this limitation on adding new endpoints made us change the approach.

We couldn't wait for new APIs to be ready to start coding it in Admin, so we decided to work with 2 sources of data: the legacy API and a new and temporary database to solve specific admin requirements.

As we mentioned above, we're Ecto fans so we chose this library to connect to the temporary database. On the other hand, HTTPoison was our choice to consume the existent API data.

HTTPoison is a very popular library for Elixir, and it makes the creation of REST API clients easy. But the fact that we're working at the same time with an Ecto Repository and HTTPoison made us wonder:

"How nice would it be if we could consume the API in the same way we interact with the database using the Ecto.Repo?"

"We could have something like a RestRepo module, with a similar interface (get, all, insert, ...), and then, when we need to switch from the temporary database to API requests, we could just replace Repo usage by a RestRepo and... profit!"

From this insight Dayron was born. And you can try it right now.


Add Dayron to your list of dependencies in mix.exs:

def deps do
  [{:dayron, "~> 0.1"}]

Ensure Dayron is started before your application:

def application do
  [applications: [:dayron]]

Then run mix deps.get in your shell to fetch the dependencies.


After getting Dayron compiled in your project, you have to define at least 3 things: a Repo, an application config and a Model. Very similar to what you do when you set up Ecto. Let's see some examples for each step:

First, create a Repo module, usually named as RestRepo, and add Dayron.Repo mixin:

defmodule RestRepo do
  use Dayron.Repo, otp_app: :my_app

Second, add the config entry with the API URL, usually defined in your config/config.exs, but you can have one for each environment if you wish:

config :my_app, MyApp.RestRepo,
  url: ""

Finally, you must have at least one Model, which defines how an API resource is mapped to a local structure. Here you can see an User model as an example:

defmodule User do
  use Dayron.Model, resource: "users"

  defstruct id: nil, name: "", age: 0

If you're already using Ecto.Schema, you may want to have a model like this:

defmodule User do
  use Ecto.Schema
  use Dayron.Model

  schema "users" do
    field :name, :string
    field :age, :integer, default: 0

Basic Usage

Now, in order to start sending requests to the API, simply use the RestRepo methods. The examples below are sending requests to using the RESTful verbs:

  • RestRepo.get(User, 'id') - to request a single resource
  • RestRepo.all(User) - to request a list of resouces
  • RestRepo.insert(User, %{name: ..., age: ...}) - to create a resource
  • RestRepo.update(User, 'id', %{name: ..., age: ...}) - to update a resource
  • RestRepo.delete(User, 'id') - to delete a resource

More info and Feedback

Dayron has a detailed documentation where you will find all available modules, methods and usage examples. Please, go to our online documentation for more information.

If you have any questions, suggestions or issues to report, use github issues or talk directly with us in our public hipchat room. We're waiting for your feedback.

Next Releases

For the next Dayron versions we're planning to support nested resources, associations and a better integration with Ecto 2.0.

If you are following Ecto development you may know it's currently in 2.0 beta. This new version is bringing several changes to make Ecto more data-oriented, and we think it's an amazing move. As José Valim wrote in his article, they are replacing Ecto.Model by Ecto.Schema and "Ecto schemas are used to map any data source into an Elixir struct".

In a near future, Dayron will be fully integrated with the new Ecto, allowing developers to use its features to handle data from external APIs, including validations and changesets support.

We hope you enjoy Dayron and help us make it better on every new release.

A photo of

Flavio Granero

Full Stack Developer