Elixir Icon

Elixir

Elixir is a dynamic, functional language designed for building scalable and maintainable applications.
16 Stories
All Topics

Rémi Prévost www.accent.reviews

Accent — a developer-oriented translation tool

Rémi Prévost: Accent is an internal tool we built to help us manage translations for the applications we develop at Mirego. We used Elixir (Phoenix and Absinthe) and Ember.js and just a few weeks ago we open-sourced the project so we could share it with the community since there are not a lot of fully-working open-source Web applications for both of these technologies. Very cool. I've been toying with the idea of a GraphQL API around our news and podcasts. I should 👀 under the covers and see how Accent's is built.

read more...

Elm Icon teamgaslight.com

Elm, Elixir, and Phoenix: Reflecting on a functional full-stack project

Zack Kayser built a Texas Hold ‘Em app with the EEP (?) stack and wrote up his findings. He calls Elm and Elixir "a match made in Functional Heaven", but the endeavor wasn't without its challenges: I personally struggled with 1) how to organize my code, especially with larger modules, 2) figuring out how to make the UI more interactive, and 3) sharing code across modules. There's a lot to learn from Zack's experience. Both the Elm front-end and Phoenix back-end are open source. ✊

read more...

Elixir Icon infinum.co

Things I wish ActiveRecord had after using Ecto

Great list, and I agree with many of Vladimir's points. However, I have to admit that Ecto's take on preloading still bugs me after years of use. I find myself doing the preload dance all over the place even when I'm well aware of the performance issues around N+1 queries. I thought I'd get used to it over time, but it still irks me every time I see an Ecto.Association.NotLoaded exception.

read more...

Elixir Icon spin.atomicobject.com

Behaviour-Driven Unit Testing for Phoenix Controllers

This is a great introduction to the Mox library written by José Valim and the Plataformatec team. Mox' philosophy: A simple summary is that when it comes to dependency injection, mocks should not be created ad-hoc. Instead, they should be constrained by predefined behaviours. This helps enforce contracts between modules, and it also makes tests easier to maintain and understand. We've been using the Mock library when testing against 3rd party services, and it works as advertised. However, we don't test our controllers in isolation like in this post. Should we be?

read more...
0:00 / 0:00