inaka

Latest blog entries

/
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

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

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

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

Meet our library to interact with RESTful APIs in your Elixir Applications.

May 24 2016 : Flavio Granero

/
Inaka's First Tech Day

Inaka's First Tech Day

May 20 2016 : Brujo Benavides

/
See all Inaka's blog posts >>

/
Replacing JSON when talking to Erlang

A photo of Hernan Rivas Acosta wrote this on August 17, 2016 under elixir, erlang, game .

What I like about JSON in the first place

JSON is awesome, supported pretty much everywhere, easy to read without any extra tools (I'm looking at you BSON and Protocol Buffers) and way better than XML.

However, parsing JSON costs cycles and they are still verbose and larger than their BSON and Protobuf counterparts. What this means in practice, is that if we are paying for hosting, we are paying extra to encode/decode the JSONs and the extra bandwidth we are going to use.

However, we already have a nice JSON alternative in Erlang, External Term Format, the way erlang communicates between nodes and that can, obviously, be processed really fast on the erlang side. As a nice bonus, though not as small as protobuff, it's still pretty compact (specially when compared to JSON, and god forbid, XML), so we can save some valuable bandwidth.

So, how hard would it be to communicate with Erlang in a way it can easily understand? Not at all really; the ETF is quite simple to understand, specially if we consider that we only need to support a subset of all its idioms.

Replacing JSONs with Jem.js

But still, writing it from scratch takes some work; so instead of just suggesting you should write it, use ours! Jem.js will support any JSON object jiffy would.

Just call Inaka.Jem.encode(someObject) from you JS code and get a nice array of bytes to send to Erlang, or call Inaka.Jem.decode(someBytes) to get a nice object. The Erlang counterparts to this two are obviously just term_to_binary/1 and binary_to_term/1 so it will be really easy to implement; just remember you are not sending application/json, but application/erlang, so set your content-types accordingly.

How does this look on the Erlang side? Let's look at an example I'm sure we all came across a few times:

handle_post(Req, State) ->
  {ok, Body, Req1} = cowboy_req:body(Req),
  Decoded = jiffy:decode(Body, [return_maps]),
  Reply = do_whatever(Decoded),
  {jiffy:encode(Reply), Req1, State}.

What should we do if we get all the requests in ETF? Just replace the jiffy calls!

handle_post(Req, State) ->
  {ok, Body, Req1} = cowboy_req:body(Req),
  Decoded = erlang:binary_to_term(Body),
  Reply = do_whatever(Decoded),
  {erlang:term_to_binary(Reply), Req1, State}.

Faster and more efficient, but why do we need to use it? Well, if you are the one footing the hosting bill, then what reason do you have not to? You'll definitely save both bandwidth and cycles with minimal effort on your part.