3

I have a SaaS platform where the user fills out a form and data entered into the form is saved to a database. The form UI has a large amount of config (originates from the DB but ends up in JavaScript) and business logic (in JavaScript). After a form is filled out and saved, the user can go back at any time and edit it.

The wrinkle is that an old form entry needs to behave like it did when it was first filled out - it needs the same config and business logic - Even if the SaaS has gone through a data schema change and changes to business logic since then.

To confirm, new forms filled out by the user would use the new/current data schema and business logic of course. But previous forms needs to behave as they did when they were created.

So I need a sensible way to version config, business logic and any dependencies.

The best I've come up with is, when the user saves their entry, to save the form's config as JSON along with the entry. When the user goes back to edit an old entry, I do not load the config from current database schema but simply dump the JSON config that was saved with the entry.

For the business logic, I save a system version number along with the entry, for example "01". When the user loads an old form, I check the version of the form and I then load the form JavaScript from a path like "js/main_01.js". When I make a non-backwards-compatible change to the business logic, I increase the system's version number to, for example, "02". New forms would then use "js/main_02.js". I also use this cheap versioning approach for HTML view templates which is getting hairy.

This approach works but it seems a bit flimsy or homegrown. I'm trying to avoid conditionals in my business logic like if version==2: do this. This approach avoids that but also has it's downsides.

I don't think the stack really matters for this convo but just in case, I'm using django/mysql.

1

Assuming that you're already in this situation:

  1. Store form config in a DB and reference the version number, rather than serialize it to Json over and over again.
  2. Don't use conditionals, just have completely separate html/js pairs and backend end points. You might have to do some internal rewrite if you want to have the forms appear under a single url.

You're facing the reality of legacy/long living/ non trivial systems. The idea is to design for changes to begin with. I'm almost certain you can refactor this into sanity. Separate the form into logical modules; each would inject it's needed markup, js (well, business logic in js is another topic) and backend processing dependencies; then mix and match via some straight forward configuration. If you don't have the time to go back and refactor, start with version N+1.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.