2 ms·
This is what I do in practice. I've seen it called a "distributed monolith". One of the good reasons to spend time with Erlang or Elixir is it'll force you to
by jerf 5y ago
This is what I do in practice. I've seen it called a "distributed monolith".
One of the good reasons to spend time with Erlang or Elixir is it'll force you to learn how to write your programs with a variety of actors. Actors are generally easy cut points for turning into microservices if necessary. As with many programming languages I appreciate not being forced to use that paradigm everywhere, but it's great to be forced to do it for a while to learn how, so you can more comfortably adapt the paradigm elsewhere. My Go code is not 100% split into actors everywhere, but it definitely has actors embedded into it where useful, and even on my small team I can cite multiple cases where "actors" got pulled out into microservices. It wasn't "trivial", but it was relatively easy.
- ravi-delia 5y agoThat's where a lot of the fun of Elixir comes from I think. It's viscerally satisfying to split off functionality into what almost feels like an independent machine that happens to be in the same codebase. It clicked in a way normal object oriented programming never did for me, I guess since it's not feasible to mint 10,000 genservers to use as more complicated structs.
- cultofmetatron 5y agohaha I was thinking the same thing. The code base of my startup is a monolith but in reality its a fork on request webserver sending messages to a collection of genservers actings as services. In essence, creating a microservice with elixir is about the same amount of effort as adding a controller in rails.
- baash05 5y agoYeah.. rails hits this same nail with jobs.. I use jobs in a synch manner, and it's great. It's a rather functional way of working within an OO world.