Well it seems what he was talking about is indeed something more ike Microservices.

I’m currently working my way through his new online course (which is awesome btw) and he says he likes to build his apps as lots and lots of smaller components.. and at the end of the video says that if he were ‘buzzword compliant’ he’d have said they were microservices.

I guess I am surprised at how small these components are - one of them is tiny, it’s a very small program that fetches a random word from a .txt file after a series of transformations! Dictionary.random_word

I suppose you could say the clue is in the name Microservices but I guess I wasn’t expecting them to be this small!

Each component/microservice is included as a dependency in the mix file of the main app (or I guess the bigger ‘component’) with a local path or GitHub url:

  defp deps do
    [
			{ :dictionary, path: "../dictionary" },
		]
  end

He mentions that if what you’re working on can be used elsewhere, it makes sense to make it a separate mix app/componant like this.

This is really interesting, particularly how they all connect to each other in an Elixir app (a very simple dependency).

I’m quite excited about this

How does this fit in with how you all are writing apps?

I’m doing something similar in my code - though nothing is quite one file tiny! Big pluses are organization and clear one-way dependencies.

It also lets me wrap up code that could conceivably be released as an open source library. I’ve only released one so far (Kronky), but there are three other candidates that I may release when I have time. I’ve got CEO approval and it’s a nice way to give back to the community.

I also assume that having different applications in my umbrella “magically” (aka I don’t really grok all the OTP stuff yet) makes my code more concurrent. For example, anything that touches an outside api is it’s own app. So it has it’s own supervisor and processes and so forth which is good? More, shorter lived processes > Fewer, long lived processes afaik.

Honestly, I’ve been thinking a lot of the same. Then I think, is it actually too much?
I mean, I want to be pragmatic. Where is it pragmatic to draw those lines?

Though, I almost always have a separate application for business logic. My web application is a presentation, authentication, and maybe authorization. Then yeah, I have things like Users is its own application.

If I have a real-time in memory state then I probably have a Persistence application that subscribes to some kind of state change emitter to write to a database in the background.

And why do you have contexts in the web layer?

I’m guessing this is instead of each context having it’s own application. In which case it is just pragmatism. I am already just using this for presentation and authentication, breaking it out seems like a chore rather than a boon.

If it’s just any contexts in general, then I would say because Threads are a different context than Profiles. A web context may have it’s own business application or may share one with another context.

Anyway, that’s just my two cents. Probably a little bit long winded though.