File Synchonization: Component Design
In the previous post we looked at context and container diagrams based on C4 model for a yet another file synchronization program. Let's also explore how component diagram can help us shape up Psy daemon.
Quick reminder: I want to build a program for synchronizing files across several computers that uses a remote git repository as a storage. The program will automatically detect changes, commit and sync them to that remote repository.
The main challenge is coming from the fact that we might have 2 parties modifying the same data. We don't want the process of local editing to be interrupted because of conflicts - mostly because this can make the local files invalid. So what if instead of having 2 git repositories (local and remote) we will use 3: local, local shadow and remote? In that case we will be able not to merge files within the local repository. We will use the shadow repository to do all the manipulations, resolve conflicts and push the result back to both local and remote repositories.
Once we make those assumptions, it's easy to create component diagram.
Git merger and git syncer components look very similar. But my gut feeling says they will differ a lot: git syncer will need to take care of SSH keys, issues with network and other small things, so it will be slightly more complex.
Some thoughts on C4 Model
The design of a yet another file synchronization program looks like a trivial thing. But I should say C4 Model helped me to produce a clear message for this blog. When designing a system it's easy to underestimate how much background knowledge is needed to understand it. And C4 helps to reduce the amount of background knowledge like that. My experience is "so far so good", I will definitely keep it as a tool in my mental toolbox.
I'm not that happy about C4-PlantUML though. The styling looks neat, but adding more abstraction layers on top of PlantUML makes it even harder to get layout that makes. For example, in the diagram above there is too much blank space and I don't know how to get rid of that. I think I will end up using vanilla PlantUML next time.