We seem to have ben able to start to separate different ORIGAM features into modules or plugins. Example: Audit, Attachments, Chat.
Some of these consist only from model (e.g. Root package itself), some might include a frontend plugin (e.g. Audit) and some might include extra resources or even full stack (e.g. Chat which adds to the server, client and model).
So far we have been bundling everything in our main build. But we expect the community to create more add-ons. We ourselves want to modularise ORIGAM so one would not need to distribute the whole thing if only parts are needed.
If we want to make the distribution truly painless we have to introduce some kind of a packaging system, like NuGet or npm.
Using GitHub Packages for storage would be a good starting point as we wouldn’t have to provide our own infrastructure for the backend.
Because as usual
Which is great. We love open source, too.
For the client functionality I think we could use NuGet client.
For model development it could work like this:
- Architect opens a model
- Detects packages (we would store them in packages.config) and makes NuGet install them
- Loads model from the
/model
folder and dependent models from the/packages
folder (we would have to support multiple model paths)
For server deployment we could incorporate it into the custom Docker build. The procedure could be like this:
- Use
origam/server:master-latest
Docker image -
git pull
from the model repository -
nuget install
would download all dependencies found in the model and put them into thepackages
folder - Model parts of each package could be left there or merged into an aggregated
model
folder. -
index.bin
could be built usingorigam-utils
so server startup is faster - The docker image would already contain the frontend source files. Package parts related to the frontend (javascript/html/assets) would be copied to the right plugin folders of the frontend source folder.
-
yarn build
would compile the frontend including the packages - Server related parts (dlls) would be added to the bin folder of the server
This DOCKERFILE would be a standard, so a developer could just run docker build
and get his image.
This way we would get a custom docker which would contain all the dependent packages on all levels (model/backend/frontend).