Right now, we have an assumption that the data / questions presented on the front-end will be relatively static.
But, it's possible that we would want to tweak questions, and the possible choices associated with such. The problem is, we would need to figure out how to dynamically resolve CHOICES and the respective field it should go into the HouseInformation table.
It's probably possible to version this based off of last updated, along with a slug to denote different versions, with an API to expose the most "recent" version.
Then, we can simply have the front-end:
1) retrieve new versions of the survey
2) notify to do said survey
3) cache old questions and keep the answers for offline
We gain the flexibility of modifying the questions at the downside of added complexity of the correct data field and choices linked properly.
Alternatively, we store JSON blobs and then somehow find a way to serialize them in the administrative interface and CSV that is exported.
Right now, we have an assumption that the data / questions presented on the front-end will be relatively static.
But, it's possible that we would want to tweak questions, and the possible choices associated with such. The problem is, we would need to figure out how to dynamically resolve
CHOICES
and the respective field it should go into theHouseInformation
table.It's probably possible to version this based off of last updated, along with a slug to denote different versions, with an API to expose the most "recent" version.
On a high level, it looks like
Then, we can simply have the front-end: 1) retrieve new versions of the survey 2) notify to do said survey 3) cache old questions and keep the answers for offline
We gain the flexibility of modifying the questions at the downside of added complexity of the correct data field and choices linked properly.
Alternatively, we store JSON blobs and then somehow find a way to serialize them in the administrative interface and CSV that is exported.