svendiedrichsen / jollyday

Jollyday - A holiday API
Other
186 stars 115 forks source link

Support for reloading of holidays during application life #128

Closed arobie1992 closed 4 years ago

arobie1992 commented 4 years ago

This isn't so much of an issue as a request if it's possible.

I got the HolidayManager working with a custom XML. From there, I'm looking into a way to create a new HolidayManager while the application is still running to prevent having to redeploy, and the two issues I'm running into are writing the new file from somewhere and validating the content.

For the writing, we're using Docker/Kubernetes so as far as I'm aware there's not a great way to place a new file in a certain directory and refresh the app the way there would be in a more traditional server setup. One solution that had been suggested was saving the content of the XML in a database table and reading from there. From looking through the API and documentation, this would require read the content from the DB, writing to a temp XML file and then reloading which seems a little clunky and potentially error-prone. Does it seem feasible to expand the API to include a create method that accepted a string that was equivalent to the content of the XML file?

The other concern sort of stemmed from this. As mentioned, writing the file and everything is a bit clunky, but my biggest concern was verifying that the content of the file was correct, both syntactically and logically, e.g. flag something like <tns:ChristianHoliday type="GOOD_RIDAY" /> as incorrect given the known rules. I have an implementation that works a little bit, but it requires actually instantiating the new HolidayManager and iterating over all the holidays to check that the required fields are present. This, in conjunction with the previous point, would require reading the content of the DB, creating any necessary backups, writing the new file, loading the new HolidayManager, and handling any potential errors and associated rollbacks/file cleanup. So I was wondering if it was possible to implement some sort of validator to verify either the XML content or some associated object model. If something like this already exists, my apologies. I didn't come across it in the documentation I found.

All that said though, I'm really enjoying using Jollyday and these aren't major concerns by any means. More just was asking if they seem feasible and worthwhile. Thanks for all your hard work and I'm looking forward to using Jollyday in future projects!

svendiedrichsen commented 4 years ago

Hi @arobie1992 , that is some lengthy description text of yours. I hope I have understood what you would like to achieve.

First as far as I see it you are mixing development and production requirements.

In my opinion you should first in development make sure to create a valid holiday XML file. Thus you should have a build which may use Jollyday as a library to test this file by using it. Invalid XML files fail to load. Afterwards you can have your test to validate the content to make sure it is correct.

Secondly to get your tested and released or labelled XML into production you could use the Kubernetes ConfigMap feature. Maybe have of CI/CD job which updates the ConfigMap of our Kubernetes cluster which translates to an updated file within your Kubernetes Pod.

Finally you need to have some interface into your application to trigger the HolidayManager cache clearing. Maybe some kind of REST call which calls the static method HolidayManager.clearManagerCache(). The next time you use a HolidayManager it will be freshly created and use your update holiday XML file.

Hope this helps.

Cheers Sven

arobie1992 commented 4 years ago

Hi @svendiedrichsen, thanks for getting back to me. What I'm doing currently is the XML is in src/main/resources and Spring loads it in as necessary. Unfortunately, the CI/CD pipeline isn't doable at the moment; we don't have enough automation for the managers to be comfortable with it (hopefully soon).

What I had been thinking in the meantime was to give a webpage where an admin user could edit the XML and then save it to the classpath, though from looking into it more, that doesn't appear to be possible how I'd been intending (JARs and whatnot). But that's where I was figuring the validation would come in. Some of the syntax errors will fail upon parsing the XML, but others, like misspelling one of the ChristianHoliday names, e.g. ESTER instead of EASTER, wouldn't cause a failure until a call was made to retrieve them. The validation was just a way to make sure someone didn't accidentally typo something and leave the app in a bad state. Obviously, ideally, that would all be vetted in lower environments quite thoroughly, but there's always the risk of human error.

I'm definitely going to take a look at the Kubernetes ConfigMap feature, though, as that seems like that might be exactly what I was looking for. Thanks again for getting back to me and for all the great work with Jollyday!