Live data from Hacker News

Learnings from One Year of Building an Open Source Elixir Application

achariam.com

21–24 of 24 posts

Re: Learnings from One Year of Building an Open Source Elixir Application

#21
post #16

Earlier quoted context omitted.

This seems to be the case in many places outside of Rails. I know that Clojure, at least, seems to encourage implementing things yourself by way of leveraging smaller libraries and modules. Auth is genuinely hard, and turnkey solutions often aren't enough.

Auth is genuinely hard, and a hand-rolled solution's definitely not enough... Given the massive attack surface for a web application, it's absurd to think someone could (or should *) develop an entire auth framework from scratch for all their projects. Turnkey solutions, like Ruby's Devise, are a godsend. Even in situations were a custom flow was needed, it's saved both me and my clients hundreds of hours. In additio…

All of what you say is true but I feel important details are lost.

Elixir's Phoenix framework has very good plugins -- like Guardian -- that give you 95% of the tools you might need for your own security solution and you can assemble it together in 15-60 minutes (this of course assumes your security model isn't wildly different than what the various plugins support). You have separate Plugs -- think of them as pipes of sort -- who handle cookie session management, another that handles JWT tokens, HTTP basic auth etc.

The only thing you must do is to assemble such pieces in a code module that basically serves as a pipeline with several Plugs (pipes) connected in the order you deem appropriate for the security model of your app. Any of these Plugs can modify or remove headers or tokens, can consult a 3rd party system (say, for single sign-on), can provide throttling, temporarily lock out an account that made too many invalid login attempts, can refuse a session due to non-whitelisted IP, etc. etc.

So no, you're not inventing cookie session management or anything there. You simply have control on which security mechanisms -- and when, and at which conditions -- happen on request.

Re: Learnings from One Year of Building an Open Source Elixir Application

#22

Earlier quoted context omitted.

This seems to be the case in many places outside of Rails. I know that Clojure, at least, seems to encourage implementing things yourself by way of leveraging smaller libraries and modules. Auth is genuinely hard, and turnkey solutions often aren't enough.

Let's not also forget that lots of projects people are using Phoenix for are APIs (either for mobile apps or single page web applications). Because of that, it makes sense to glue together smaller libs to match your house style for how you want that auth contract to work.

Can confirm. Currently working on several Elixir API apps, they are absolute joy to work on and you get tons of freedom on how exactly to structure them.

The "cruft" from the Phoenix framework is absolutely minimal -- mandatory 4-6 files per project at the most. And they're quite small, too.

Re: Learnings from One Year of Building an Open Source Elixir Application

#23

Interesting post, more so because I am working on a project that has many characteristics of a link aggregator. While implementing the ranking algorithm, which is very similar to the one mentioned in the article, I decided to run a periodic job every 60 seconds that updates the rank for each submission and stores it in the database so querying the ranked data is more efficient than recalculating the rank on every pag…

> Once you start to scale, the bottleneck is rarely the application layer. For the typical crud web app it's likely to be the database.

You seem to be downplaying the importance of an efficient app layer and I respectfully disagree.

1. Using well-optimized tech for the app sends you right at the DB scaling problems phase, so you never go through the "our app layer is too damn slow" phase -- which can kill a startup pretty damn quick (and history knows examples). So, it's a huge win in my eyes.

2. Most apps never even take off to the point where the DB is the bottleneck so a strong app layer is a godsend; I'd estimate 80% of the apps struggle with optimizing backends and caches and not DBs -- at least judging by my 15 years of career which, I admit, is anecdotal evidence and doesn't mean much.

3. Those apps that do scale that far are very grateful to their backend engineers who spared them all the "tune our Java / Ruby / PHP / Python VM's memory usage and GC behaviour parameters" dance (and that dance can last for weeks and weeks almost without sleep!).

Re: Learnings from One Year of Building an Open Source Elixir Application

#24

I really enjoyed this article and the one about the ambient notification cube! Well-written. It's nice to hear someone else talk about how hard it it to stay consistent with worthwhile projects while maintaining a day job. Congrats on sticking it out!

Thank you for the kind words, really appreciate it :)
Post reply on HN