The container and the submodule truly act as independent repos.
Submodules, like subtrees, aim to reuse code from another repo somewhere inside your own repo’s tree. The module has its own repo, somewhere inside the working directory of its container repo. At deployment, a specific commit hash is pulled into the larger repositiory and deployed.
Makes working on extensions by ISVs similar to application development where they are exposed an API.
- ISVs don't need access to any existing code at all; just definitions
- Far better compartmantelisation than giving access to existing repositiories
- Keeps coode architecture clean; ensures proper API specifications
- Have native git support since a long time
- haptik_api developers don't have to or need to think about this at all; only pullled at deployment; used quite a bit in OSS for this reason
- Internal API needs to be defined
- Testing needs to be figured out
- haptik_api already has everything set up for the use cases
- does not mess up the architecture of message_delivery
- even easier to split out in future
It's kinda like packages but without the overhead of packages, thought the advanced dependency management of packages is definiltely better. In case we're willing to take that overhead...