Thank you for the great work building LiteFS. I would like to understand better the design considerations of the following.
Going through LiteFS tutorials and example I notice that LiteFS is the main process and we ran the our app as a subprocess to get (this is also mentioned in this thread about properly configure a LiteFS deployment.
I would like to understand better what were the considerations to this design and not having the app as main process and LiteFs as a subprocess.
I understand why we need LiteFS to start before we work with SQLite db of course, but there are downsides of having our app as subprocess of a different external process (LiteFS in this case).
Good question. There are two main design concerns with the subprocess setup:
It works well in a Docker set up where the
ENTRYPOINTcan only specify a single process to run. As a subprocess, if either the application or LiteFS quits then the whole thing can get torn down. Another option would be to use a supervisor like s6 but that’s a lot more complicated to set up.
It’s helpful if LiteFS can perform setup before the process starts (e.g. becoming primary or syncing with the existing primary) and can perform teardown after the process finishes (destroying the lease, flushing to replicas, etc).
All of this is possible with separate peer processes too. The child process model was just simpler for most people. What’s the architectural issue you’re having in your instance?