I’m working on a web application that sits on top of a number of RESTful web services, interacting primarily with those services through JSON formatted messages over HTTP. Our application has a great deal of static data that are read from these services (internationalization lookups, configuration, etc.) during operation.
Unfortunately, we work pretty closely with the team who develops the webservces, so we know the backend architecture fairly intimately. Most of the services are using a MongoDB store for persistence, and our strategy thus far for managing the static data we require to be loaded is to utilize MongoDB dumps committed to version control that are loaded at deploy/upgrade time.
We’d like to decouple our static data from the persistence store. The best ideas that have come forth thus far mostly involve storing static data formatted as it would be passed to services (JSON files) and then writing a “loader” process/script that will live as part of the deployment process which will interact with services to load the data.
Are there patterns/strategies for managing/loading/deploying “application” data to services?
3
It would seem you’re approaching the problem correctly. Add a layer of abstraction between your database and static data so that the receiver always gets the same thing. It may require a little rewiring, but the end effect is that the back end can change any number of ways but the front end still gets the same format everytime.
I don’t know what language/libraries you’re using to convert to JSON, but I would recommend GSON if you’re using Java since it has a system to convert any object into a JSON counterpart. With the help of annotations, you can also control which properties you want to be converted into JSON.