How to decide whether a certain action should be done in the backend or the frontend?

user_3637700 0
Viewed 184

So lately I have noticed that what dramatically reduces my productivity is spending time on trying to decide whether a certain action I should do on the backend or the frontend, modelling my databases and so on. And please keep in mind, I am trying to find the balance of being productive and at the same time keeping quality, and so it seems to me that I am falling into the "premature optimization is the root of all evil" thingy, in my case, reducing my productivity dramatically.

I am trying to figure out a, framework lets say, that will allow me to make these decisions easier.

For example, right now I am making a simple functionality, and I'll be specific, because it will be easier, so I have a functionality that allows the user to add a skill to the mongo document for skills, the problem occurs with the requirement that skills must be unique, for example only one skill named "Javascript" can be within the database, and so a check must be performed, the question is, where and how do I do the check?

There are of course many possibilities, but the two main ones I have in mind are:

1.

  • The user fills the form with the skill name
  • the data is sent to the backend
  • the backend attempts to create that skill
  • mongodb returns error that it already exists
  • error is sent back to the front end and displayed to the user

This approach works just fine, however the drawback imo, is it takes time and does not allow the user to see his mistake in "realtime".

2.

  • While the form is opening, send a get request to the server to get all currently existing skills is made
  • the user fills the form
  • as the user is filling the form, the check is performed in realtime with every pressed key, and so the user gets instant feedback if the skill already exists.

This would also work just fine, with the drawback, that if the collection of skills is huge, and a search must be performed on that collection at pressed key, processing will depend on the users device and the size of the collection, which could potentially lead to bad user experience.

So does this dilemma boil down to the expected amount of information to check against, if a collection is never expected to be huge enough to cause a problem do 2, if not, go with 1?

Do I start with the second approach and later move to the 1st if performance suffers at some point?

Do I go with 2 and use some more complex data structures that will allow for faster searches to mitigate that potential performance issue?

Keep in mind please, this is just one example, the same decision can be extrapolated to many other similar scenarios and thats whats tripping me.

responsive-design architecture design-patterns
2 Answers

Looking from the user perspective - you don't expect that after filling the form you gonna receive an error

error is sent back to the front end and displayed to the user

How can I know, that something was already in database?

For this use case, in order to make a good UX - I would use some component, that would support your requirements, such a multiselect with an option to add new item - or tags input like here (other components library should have something similar)

You can either prefetch all existing items upfront, or make a request after couple of keystrokes (debounce) - to limit network traffic.

Validation should be done on backend as well, but this should be rather transparent

user_30614690

Trying to asnwer the question "how to choose how to implement" meaning "which criteria should you concern", I would say it depends on which aspect is most import to your application.

Prefer only implenting a front-end solution when:

  • You don't have time/resources/permission to do a backend implementation.

  • You are dealing with an application which will be used by users inside a controlled environment (e.g. inside a company) and do not care much about security or data consistency.

  • Generally, front-end implementation are easily changeable by running some client-side script and lead to inconsistent data in your database. Imagine what would happen on your second scenario, an malicious user could cheat your app and confirm a change on database because there is no backend validation.

  • If you do not persist data on backend (e.g. localStorage), because it could lead to inconsistent data.

  • If your data have only one source of data change, because it could lead to inconsistent data.

In a real app, I would recommend implementing both in front and back-end as it:

  • Leads to better data consistency, specially if you have multiple sources of data.
  • Leads to better UX, because users do not need to wait until the end of their interaction to have feedback about what are they doing.
user_4061100
Related