GitLab

The current setup for xsweet conversions (docx to html) is as follows:

There is a docker container that contains both the necessary code for xsweet conversions, as well as an api endpoint that gets attached as a pubsweet component. Conversions are then wrapped in a 'job' that gets registered with pg-boss when started.

This causes a number of issues:

• There is an awkward setup where the docker container must run after the server has finished starting, otherwise there is no place for the api endpoint to attach.
• The container for conversions is bound in a 1-to-1 relationship with the app. This means that for every app deployment, one container with xsweet must come with it. This will cause scalability issues down the line.
• The feature is bound to pg-boss, which we might want to move away from in the future.

The expected outcome of this issue that fixes the above is to:

• Use xsweet as a completely independent micro-service (with its own db). This will allow deployment engineers to scale xsweet deployments independently of the app and to potentially use the same service for multiple deployments of kotahi (or other apps like editoria). The code for this service already exists here. We will need to add it in our development docker-compose file.
• The api part of the feature should move to the app's server code.

The one thing we lose with this is the job queue part of conversions, but this can be added to the xsweet service (if needed) down the road.