It is friday afternoon and I am a tired man. This is the common case around fridays. The week wears on the brain and I recover pretty well over the weekend. It is a surprisingly reliable cycle. I just have to be mindful of my mood and aware that I'm usually a little bit thinner of skin than the guy I was on monday.

Some of my readers have definitely found their way into the Professional Mentorship offering on my site. That's very cool. I enjoy the sessions a lot and the mentees seem to be getting what they want. If you are interested in mentorship, give it a read.

My vlog habit imploded the first time I recorded something I wasn't happy with. I have some thoughts on a reboot but have also been a bit too busy so I haven't pushed to revive it.

What did happen since last time is a new site design which was done on commission by Luke Twyman (Twitter, website portfolio). I'm quite happy with how it turned out and I'm looking forward to pushing that visual through in other mediums as well. This newsletter should probably be on that list.

Publishing since last time:

• Stupid solutions: Live server push without JS
• Supervision trees, an example in Elixir
• The BEAM marches forward

The reception on the Stupid solutions one was good with some serious Hacker News attention and some fun discussions, which gave new and deeper examples of terrible approaches in the space. Loved that.

Supervision trees is just a convenient example that I think might help people when googling for examples. Nothing new there if you know Elixir well, but worth looking at if you are still learning or find the child spec stuff confusing.

"The BEAM marches forward" has had a very warm community reception around Elixir which I appreciate. The tail end of that post covers that "The BEAM can be your entire application" and that's part of what I want to bounce off of you today.

So Rails, Django, et.al. made CRUD apps easy

Since the creation of Rails and friends web application development has evolved in an ongoing fashion. Things that have become more common in recent years:

• Metrics/App analytics
• UI by way of declarative components & state management
• CI/CD
• Distribution & clustering

What does the 80% use-case web stack look like?

• HTTP server, usually Nginx for static files and reverse proxy to app server
• Application server, particular to your backend language
• Cache, usually Redis
• Background work, usually a message queue or cron
• SQL Database, preferably Postgres ;)

While I was working with Python putting something in front of Gunicorn or uwsgi was a strong recommendation. When working with Elixir and Phoenix I've found that the reverse proxy HTTP server isn't as necessary. It can be nice if you want to control static serving in configuration and stuff. But it can also add a potential complication to your connection state and honestly for some workloads the BEAM is more flexible with less configuration. Nginx is fast and fantastic. But if you can cut a piece of software from your stack because it isn't needed. I call that a win and I've found this doable.

Application server, depending on your language this might be integrated or separate. For Elixir applications it is very much just part of the dependencies and deployment. You don't consider it separately in any fashion.

Running a separate caching system when you are on the BEAM is very often an anti-pattern and almost to the point of code smell. It might be the right call for certain workloads, but generally you have access to powerful caching patterns and in-memory data stores without standing up a separate service for them. So I think we can remove it (remember, this is the 80% case).

Background work has a well-supported mature approach in Elixir currently called Oban. I like it. It feels pragmatic, it relies on the database to do most of the complex single-source-of-truthing and can be incredibly flexible. There are a few other options that fit other scenarios. Broadway is good for batch processing at volume for example. Oban fits this idea quite well since it doesn't expand beyond your BEAM application. No extra infrastructure. You get scheduled jobs, you get manual jobs, you get concurrency control, you get uniqueness, retries and more. Very capable.

SQL.. now this is not my thinking, Saša Jurić put this in my brain and it won't leave. He argued that a simple but good enough SQL database that is implemented on the BEAM and can run embedded inside a BEAM application with Elixir or Erlang would be a killer app for bringing down complexity of web app development. And I think he's right. I think he's right in SQL being table stakes just for the flexibility it offers. I would love to see something like CockroachDB for Elixir. So this may be the important missing piece.

But what about the operations end? Or devops, since we're very much in dev territory with our ops here.

Metrics & app analytics. We have Phoenix Live Dashboard which gives a zero-effort dashboard that can show a bunch of information about your system and application that is extensible with whatever you might need. This would be a poor choice to shove into most types of applications but it sits quite well in the BEAM model.

UI components & state management is probably the most hyped thing we have in Phoenix right now where LiveView is just throwing most of the need for JS-heavy development out and providing another model, uniquely suited to the BEAM.

CI/CD isn't something we have but it seems The Erlangelist is taking that on right now. Chris Keathley of Elixir Outlaws fame also recently told a story about how Bleacher Report is doing some internal work for CI/CD rather than using an off-the-shelf thing.

Distribution & clustering, yes, we have that. It has been in there since ages ago. It is what it was built for. There have been some modernizations on top of the basic model with things like swarm/horde/libcluster because the default model might be optimized a bit too much for phone calls, or so I hear.

I think the offering that Elixir and Phoenix already provides is quite compelling. But I'm also seeing the outline of a future which doesn't require anything outside of your BEAM application. And I find it interesting because I think the BEAM is a very stable fulcrum and to me it seems like the community is hard at work building some serious levers with which to move (at least the middle 80% on the bell curve of) the world.

The way Rails allowed you to build a blog quickly back in the day by leveraging powerful conventions I'm curious to see all the things that we don't have to do in the future. I think Elixir and Phoenix are achieving this in a more maintainable fashion. Less magic, more explicit and on a runtime that won't be a liability down the road.

The BEAM has traditionally been used to build systems. Not just applications, systems. The way this works is very different from what you see in most other languages and runtimes. It is a very reliable basket to put eggs in. And it is built to support running as multiple baskets, it also scales well horizontally as the concurrency store is quite good.

I'm seeing a future where startups can actually ignore most specialized, costly cloud features and just put their application on bog standard VPS:es and get everything they need.

What do you think? Will you miss managing all the services? Am I full of sparkles and hope  but blind to reality? Will Docker and the Kubes beat the hope out of this ever happening? Happy to hear your thoughts. Feel free to reply or email lars@underjord.io.

Thank you for your time and attention, I appreciate it.

- Lars Wikman