CODEWITHSUNDEEP
angularweb-applicationsarchitecture
Sam K
Sam K

Reputation: 410

How to build a seamless UI experience for users?

This is a kind of architecture question. If we take a simple scenario, say I want to create a folder on the UI and a record should be created on the DB. What is the best way to achieve this?

  1. Show the changes in UI, and then make a call to DB to write a record
  2. Write a record to DB, once it is a success, refresh the UI
  3. Create a queue, pub-sub model, where the requests to DB are queued and can be processed at any time, but the user will have the latest UI available.

I have seen a couple of applications that creates the element on UI in a flash, so just wondering how they do this. When I do this on Angular, the node server which communicates with DB is going to take at least a few microseconds.

Please give me your thoughts, it will be great help for my project

Upvotes: 0

Views: 75

Answers (2)

Pierre Sevrain
Pierre Sevrain

Reputation: 699

As to me showing your user a wrong situation can be devastating. It can lead to intractable situations. And having some communication problems over the network is not so rare...

If you want to give a nice UX for your user, make the transaction asynchronous, show a pending information, and display a message when success or error. If the operation is mandatory to continue the work on the application, then you really better wait for being sure it succeeded.

Upvotes: 0

Marcell Kiss
Marcell Kiss

Reputation: 556

this is a well-thought question and you offered great solutions right away. I don't think there is an 'industry standard' for this, I think every situation is different and the final choice is up to the developer.

Let's see the pros and cons

1.) 'UI first' provides the best user experience, no doubt. Although, the request may be interrupted due to unexpected conditions (no internet, or whatever)

2.) 'Transaction first' is the secure option, you really see, what happens. This won't make the user extraordinary happy, but at least they can trust the system.

3.) Building a queue system shouldn't be the responsibility of the frontend. Sending http/https requests is a really lightweight operation and it's asynchronous by nature. The server can apply such a logic, if it's required due to overloaded resources.

Summing up

We're talking about a trade-of between UX & reliability.

You have to answer one single question: How critical is the actual transaction?

If it's about processing credit cards, reliability is preferred.
Otherwise, if the transaction is not that crucial, try to satisfy your users. The chances are basically very low, that you can't execute your request in the background.

Upvotes: 1

Related Questions