I try to wrap my head around the boot process for dry-web-roda apps, currently looking both at an umbrella style app and a flat app. Especially the umbrella app is quite a lot to take in when it comes to what files are loaded and in what order.
One thing that might help me is to better understand why the different parts are placed where they are. If I look at the umbrella, I think the sytem directory could be looked at as configuration, while the lib directory is more “general” code. But in the sub apps (and in the flat app) some of the corresponding files to the ones in the umbrella’s lib directory are located in the sub app’s system directory. E.g there is a lib/my_umbrella/transactions.rb but also an apps/my_sub_app/system/my_sub_app/transactions.rb, and there’s a lib/my_umbrella/repository.rb but a system/my_flat_app/repository.rb. What is the reasoning behind this?
Another thing I don’t understand is why persistence isn’t under the apps “namespace” in the lib directory? I like to think of anything in my lib dir as something that could at any point be extracted into it’s own gem, so it should be properly namespaced. But a general Persistence module isn’t. I realize my personal view of the lib dir probably isn’t that interesting to the project, but would still appreciate some insight in how you think about it. To me, placing persistence either under lib/my_app/persistence (“this is how persistence works in this app”), or under system/my_app/persistence (“this is how we currently configure persistence”) would probably make more sense.
This dir includes core parts of the stack, like container, import module definition and bootable components, thus can be treated as configuration. Also notice it’s system by default, but you can rename it to something else.
Yeah lib is used for code that can be extracted in the future into reusable gem shared across multiple applications.
No reasoning whatsoever to be honest. It just ended up like that. Library code shared across multiple apps should live under lib directory. Maybe we put transactions there due to loading order constraints. Where’s the code you’re referring to?
It’s really up to you. You can namespace classes however you like. We just added a top-level persistence namespace to indicate a standalone, separate persistence component, that we could extract. There’s really no reason why persistence couldn’t be under your application’s namespace.
One thing I don’t like is that repositories are under persistence namespace. These days I prefer to keep them under application’s namespace and name them using #{entity}_repo convention, ie apps/admin/lib/admin/entity_repo. Repositories sit between persistence and application “layers”, so it’s nicer to name them like that and keep under app’s namespaces.
Hope this explains it a bit better
Let me know if you have more questions, and sorry for this late reply, I was away without internet.
