Do logic on the backend or front end? When handling the results of a "wizard"?

Question

We are creating a SPA, and thus the frontend is more than just a view for backend generated pages.

Now to create an "entry" you normally press create, and then fill in the data for that entry in the resulting page. (as admin you can view and edit in the same page that others can view).

to help generation we created a "wizard" or "template" - where you select the template and a few options and then it fills in a lot of the data automatically.

Basically instead of an "add" button the "add button" shows a popup where you select the language what template and a few more options. and then click "create".

I am however wondering where such code should live. Because what is the user actually doing:

Is the command "create a new entry with template xyz, and options A B C" -> so the backend gets the template and the options; and then the backend is responsible for this?

Or is the command "create a new entry, and fill in the data from the templates". The latter would mean you send the command for an empty entry first and then send a command for each option automatically after the empty one has returned.

I've tested both methods but I did not really notice any notable difference in how it works for the end user. Obviously the second option has more overhead as more requests are made (one for each "setting") but that is trivial, and is offset by the fact that the page seems just slightly more responsive (control is given back the moment the entry is initially created, which is ever so slightly fast when the entries are first empty).

So I am now looking from a code technical point of view: are there any reasons to chose one over the other?

Answer 1

The best answer is "both".

• You must always at least verify the correctness of the request on the back-end, because you shouldn't trust the client.
• Good UX usually involves also validating it on the front-end so that you can give early feedback to your user if something is wrong - e.g. if they are supposed to type in a rating out of 10 for something and type in lizard, you can highlight this as an error as soon as they type l and not wait for them to submit the form in any way.

• paul23: Of course the validation happens on the backend, the question is basically: send one big "generate" and then wait for the result of the backend. Or send a lot of "update this field" "update that field" command. It's not about editing but about the initial creation after selecting stuff in the wizard.
• paul23: To stress: the interface itself has all those double checks. It's about the results of the wizard: do I send "create an organization and use template big-international with hometown amsterdam" - Or do I send "create an organization'. "set hometown to amsterdam". "make international". "set number of employees >100" .....

Answer 2

Is the command "create a new entry with template xyz, and options A B C" -> so the backend gets the template and the options; and then the backend is responsible for this?

Or is the command "create a new entry, and fill in the data from the templates". The latter would mean you send the command for an empty entry first and then send a command for each option automatically after the empty one has returned.

On the backend, I wouldn't care where the values come from, so from that perspective, I would offer an API with a single call to "create a new entry with these values".

It is then up to the frontend to decide how they are going to collect the values, which could be just a simple form (and hope the user fills it correctly), or getting some values from the user, some values from a template and calculating some others.

And either of the two options you thought of can also work.

The first one has the consequence that there is a tighter coupling between the frontend and the backend, because the backend get knowledge about the templates.

The second one has the consequence of an increased network load, because it takes more requests to fill all the properties of the entry with the right values.

• paul23: Reason for not "collecting all and sending at once" is that there's been no need, one of the design parameters was that editing should directly update: so if a value is valid on removing focus on a field (and every so often) the fields are stored to the DB. Hence the only need was for single field updates. -- Except now with templates/builders that generate a lot of fields at once.

Answer 3

The simplest is to collect all the information in the frontend UI and then send it to the backend as a single transaction. This cleanly separates the UI concerns from the backend logic.

Answer 4

Both approaches have merit; each has advantages in different situations. Here's a few off the top of my head but I'm sure there's many more.

Single submit

• Allows the back end service to be stateless, meaning in many cases it will scale better.
• Typically the transaction processing portion of the application will be much simpler, as there is really only one transaction that has to be processed.
• Allows you to make changes to the workflow on the front end without changing any code on the back end, which usually means less regression testing and quicker releases.
• May offer a more reliable user experience in areas where connectivity is inconsistent.

Multiple submit

• Allows the user to save their progress as they go. This can be important in long workflows, such as a mortgage application.
• Allows the back end to perform validation before moving forward in the workflow, e.g. in a registration workflow, the back end can ensure the user name isn't already taken before asking the user to choose a password.
• Allows better site intelligence, e.g. if many users abandon the workflow you can see how far they got before they bailed out.

• paul23: Welll the bigger question is: should a template "simulate" as if it is the user sending lots of update commands. Or should the template have it's own api end point so that it can be created at once. I already go for the "multiple submit" approach in the normal flow, but what when a choice (picking a template) has multiple "changes" implied. Send a single command or send the changes separate and ignore template logic on backend?