Replace jiffy by jsx

[BernardNotarianni]

We are using cowboy-swagger for barrel-db and we would like to remove the dependency to jiffy and use jsx instead.

Here is a proposition for this refactoring.

Bernard.

[elbrujohalcon]

Hi @BernardNotarianni … I've been under the impression that jiffy is somehow faster or more performant than jsx. Nevertheless I like the fact that jsx requires no hacks to compile.
I'll let the team at inaka voice their opinions on this matter. If all goes well, I'll merge it.

[gadgetci]

According to Dialyzer:

Invalid type specification for function cowboy_swagger:enc_json/1. The success typing is (atom() | binary() | [any()] | number() | {{non_neg_integer(),1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12,1..255},{byte(),byte(),byte()}} | map()) -> binary()

[HernanRivasAcosta]

I am extremely convinced that measurable performance gains at runtime trumps having to write (or, to be fair, copy pasting) a couple of overrides in the rebar config.

To be honest, I think it's a bad idea to move to a slower alternative to gain a bit of simplicity. If you really want to do this, I would suggest a fork, but I would suggest even more strongly to just use jiffy.

However, I am coming from the assumption that jiffy is faster, which I have yet to measure myself. I will run a few benchmarks before giving a definite answer, but I will always side with performance; specially since we can expect the JSON encoding/decoding code to be called at least once per request; if there's any part of a web server that could use an optimization, it's that one.

[cabol]

IMHO, I think PERFORMANCE shouldn't be a reason to keep using jiffy, because from cowboy-swagger perspective, PERFORMANCE is not an arquitectural driver, it was designed and build to serve documentation, from that point of view, if it takes some milliseconds more decoding/coding JSON, it is not a big deal – remember, API doc is requested on-demand by a final user. Furthermore, supposing you want to use cowboy-swagger, the JSON lib you use in your project is totally independent from cowboy-swagger (cowboy-swagger would use jsx internally), in other words, your App can use other different lib for JSON – like jiffy if performance is a real issue for you.

On other hand, I'm not saying we should go for jsx neither, my point is, we should make a decision based on what would be more practical to the project (cowboy-swagger). So, my question for @BernardNotarianni is: what is/are the real need(s) to move from jiffy to jsx? Why to do this change is important to you guys?

[BernardNotarianni]

I quite agree with remarks from @cabol.

Moreover, our priorities are currently :

1. Simplicity
2. Reliabily
3. Performance

Hence, in similar context, we would prefer a full erlang lib over the one including parts in C, unless other constraints come in. That's why we chose jsx and we would like now to avoid to package 2 json libs.

I do not have stronger cons against jiffy. If it is your standard choice for your applications, I fully understand you will not want to have dependencies to 2 json libs too 😄

If you decide to keep it, I guess we will be happy with our own fork, as swagger is not a critical part of our core.

[elbrujohalcon]

@BernardNotarianni we're discussing this internally, but in any case… it would be nice if you can fix that dialyzer warning above :)

[BernardNotarianni]

Sure. Sorry about that.

[BernardNotarianni]

@elbrujohalcon it looks like I fixed one problem but created a new one 😢

However, I did not find where I could have more information about the errors. Any clue?

[elbrujohalcon]

@BernardNotarianni a link to details should appear there… it's a bug in gadget. I'll check it out myself.

[elbrujohalcon]

…aaaand merged! Thanks @BernardNotarianni !

[BernardNotarianni]

Thank you for you time 😄