Publishing Without End User Intervention (auto publishing)

Current process

  1. The backend stores application settings, as well as compiled SCSS
  2. The front end designer application uses these application settings to generate SCSS using business rules internal to the application
  3. When the user is happy and publishes their site, the designer application compiles the SCSS into CSS and passes that to Gateway, and ultimately to the Publish Service in the backend
  4. This CSS is written to a file in Azure Blob Service, and the HungerRush API is notified of the publication
  5. Internal HungerRush service workers fetch the CSS and publish the user’s site

The Request

Occasionally, there are minor style fixes made to the rules which generate the CSS. HungerRush would like to be able to roll out these fixes without the direct intervention of the end user. Hence we have implemented an Auto-publishing feature to cater for this use case.

Complexity

In the current implementation, there is a large set of rules which are responsible for converting application settings to SCSS. Currently, the source-of-truth for these rules is the front end Designer application. As a result, changes to these rules necessitate the execution of the front-end application is required to update the SCSS and the generated CSS.

Solution

The following outlines the solution for the above requirement.

  1. Implement business logic in the publication service which replicates the rules-to-CSS functionality.
  2. Add functionality to the History Service which records when a historical item is being saved due to a publication. This precludes the ability to find sites which have been published before the date of implementation. This would only work for sites published after the date of implementation of this new History Service feature.
  3. Implement a query on the History Service which finds all site IDs which have been previously published.
  4. Implement a Styles service that handles generating the same styles rules the FE generates.
  5. Implement a new endpoint on the Publication Service which represents the new migration functionality which will ultimately publish all of the previously published sites.
  6. Implement a resilient queue to queue all site IDs for republishing.
  7. Implement a service worker to idempotently consume the queue, apply the rules from the rules engine to generate new CSS, and queue the sites for publication through the existing publication queue.
  8. Implement a mutation on Gateway which triggers the migration functionality.

Note: This represents a duplication of the rule’s logic. Since we have to maintain FE & BE SCSS generators the maintenance to those rules requires duplication of work, increasing the cost & time of maintenance.