> Elyxel was designed and built with performance in mind. Styles and any additional flourishes were kept to a minimum. My choice of Elixir & Phoenix was driven by this consideration as well. Most of the pages are well under 100 kilobytes and load in less than 100 milliseconds5. I find it's always helpful to keep performance in the back of your mind when building something.

Thats much appreciated but I was kind of hoping you (the author) would go into more details about request time. Most people can (and should) do the above. However I would be more interested in what Elixer + CRUD is like particularly for TTFB. Like does the author do streaming (I don't necessarily mean websockets or comet)?

After all if the TTFB is really slow the CSS optimizations and what not matter little.

In traditional request per thread (or whatever is analagous) web framework paradigms the request is a single thread and often waits for the database to finish before moving on to display the page. I would imagine Elixir has a better answer at least for read only pages.

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!

One of the interesting things about the Elixir/Phoenix community is that building your own authentication system seems to be encouraged. Even if you're using one of the plugs available (guardian?) you still have to do a ton of manual lifting.

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 page request. Are you doing something similar or did you take a different approach?

Ranking all stories works well if the total number of submissions is a small number, but I imagine the approach is a little different for large sites like HN. Ranking all submissions periodically seems like a waste since people rarely view submissions beyond 10 pages. One approach is just to rank submissions from the past n days, where n depends on the average daily submission volume.

For the part that displays time since a submission was made, I implemented the HN model, where it displays only minutes, hours and days. Python code here : https://dpaste.de/5d1w

> Elyxel was designed and built with performance in mind. Styles and any additional flourishes were kept to a minimum. My choice of Elixir & Phoenix was driven by this consideration as well. Most of the pages are well under 100 kilobytes and load in less than 100 milliseconds5. I find it's always helpful to keep performance in the back of your mind when building something.

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.

Great writing. Elixir/Phoenix has been on my radar for learning something exciting considering it is faster out of the box and can handle tons of concurrent connections.

For the lazy, here is the github link from this article:

https://github.com/achariam/elyxel

Having a sign up button or perhaps context or text on the site might've been helpful...

It would be awesome if elyxel.com wasn't so esoteric.