6 ms·
This feels like a bit... too much. If you’re really going for microservices, that means every service will be small and specialized. Do you really need to split
by ramchip 9y ago
This feels like a bit... too much. If you’re really going for microservices, that means every service will be small and specialized. Do you really need to split it further into so many sub-apps? I feel like the S3 app is going to end up as one module with a handful of functions.
- rothbardrand 9y agoThese are medium sized. Remember in elixir it's perfectly convenient to map across a list by spawning a process for each element in the list and sending the function you want to map to that process, and then they collapse down and get reduced. A process (or application) in elixir is no big deal, just think of it as a module or object that lives in its own process, probably has a set of processes and all that... If you were writing this in go you might call it a monolith because all of those "Apps" would be in one single binary executable.
- ramchip 9y agoMy comment is about code organization, not process usage. You can have 6 separate apps and still do everything in a single process. By splitting into lots of sub-apps, you end up with a deep folder structure like `my_service/apps/s3/lib/s3/query.ex`, each app having its own versioning, configuration, tests, etc. That makes sense for a sizable codebase, but for a microservice, I don't think the added complexity is worth the benefit. It can be organized very cleanly with just modules and folders.
- novembermike 9y agoThese aren't sub applications, they're more similar functionally to classes, although they tend to end up a little larger in a lot of cases.
- ramchip 9y agoThey are applications. That's what an umbrella does, it groups multiple Erlang applications into one project.
- anon4728 9y agoErlang processes are cheap, unlike OS processes. More, the merrier.