It’s good practice to separate your API and your user-facing website, so I am seeking some advice on how to structure the module/sub-module layout for a Python project that has simultaneous API and front-end development.
When currently deploying, we have two different machines: one is the web service, which uses the API, and the other is the web app.
One way I was thinking of approaching the problem, is to build out a minimal core super project that initializes the configurations, manages testing execution, application launching, daemonizing etc..
Then, abusing Git sub-modules, separating the web app from the API sub-module which can be developed concurrently.
This way, there can be versioning for the API (the specific commit revision) as well as web app deployment that do not interfere with each other as long as backwards compatibility is enforced.
A few cons with this approach:
- It’s tied to Git
- Breaking API changes still require the web application to be restarted (but that’s the case with any service building around an API)
- git-submodules might be overly complicated and hard to understand for new people (not sure about this one)
Once we have enough bandwidth, we can use something like zc.buildout to use a build-system to deploy.
One other solution, is to just use zc.buildout immediately and have one master repository and just construct the python release files.
Thoughts?
I would definitely keep them as different repositories. The super-module is up to you. Not having them as submodules doesn’t prevent you from doing tags in both repositories so that you can keep things in sync for different releases. Your point about submodules being overcomplicated is correct and if you do so I would think of it only as a way to keep certain releases in sync. I think of submodules as being designed to add remote libraries to another project where you actually need to use those submodules but other people are developing them.