Need to know Response time of ODATA in frontend apps

[jagesh_lakdawala]

Hi Experts,

I am being involved in my first mobile apps project, system architecture is SAPUI5 framework being used as front end developments, SAP NWG (central hub) for providing the ODATA service which in turn access the RFC of the SAP R/3 backend system.

Application consist of login page, then home page contains the left panel with multiple links (3 links).

on the click of each link, in right hand side panel search box and Table control is to be displayed with the Header data, and on selection of any record from the header data table control, next screen should display the detailed data which may in turn contains the few links for further details on new screen.

While designing the flow for this app, I have got the below query.

After the successful login, should I load bring all the master/details data from backend system for all the links (total 3 links in left side panel) in one shot. so that later when user wants to see the details then simply I have to play with data residing on client side, this is I am thinking to gain the faster speed on mobile apps.

second approach would be, after the successful logon, lets bring only the minimum required data on client side and then further as and when user clicks on record or link then at runtime through another ODATA service I should pull the data from backend, here in this approach I am worrying for the response time when user clicks on any link and data comes from the backend.

for your reference, RFC in backend system returns the maximum 50-100 records as a maximum limit  (each record contains the 20 fields at maximum),

business user wants apps should run faster and there should be minimum wait time.

please suggest.

Regards,

Jagesh

[pavlo_denysyuk]

Hi , Jagesh. I am not an expert, but would try to suggest some usefull ( as for me ) ideas )

     I suggest to create backend configuration ( SPRO ) for setting when master/detail data would be fetched . 2 options possible : After app starts it loads everything  or data is loaded step by step. I am sure it would not be too difficult to implement and client would be able to manage loading process ( as there might be huge backend or small/middle one ) . That way it would be more flexible I believe !

     Concerning timing. You could simply use console.time('anyID') when request is sent and  console.timeEnd('anyID') after response received. That way you would see in console how much time was spent.

     Hope , sth. would be helpfull ! 

[former_member185414]

Hello Jagesh,

The data which is required to achieve the intended functionality by end user should only be retrieved and nothing else should be fetched.

Reasons are -

1. This makes apps adhere to Fiori design principles.(https://experience.sap.com/fiori-design/foundation/design-principles/)

2. It will not unnecessarily delay the initial load time of application.

3. Application will always render the latest backend data because the calls to fetch the data will be made in real time and no old data would be used.

BR.

[jagesh_lakdawala]

Hi Ankit,

Thanks for your reply,

can you give me some rough idea on how much time generally it takes when front end apps brings the data from backend system at runtime, that is on click on button etc..

in my case it is not the huge data, approximate data are 20-30 rows with around 20 fields.

Regards,

Jagesh

[former_member185414]

Based on my reading and any internet user's behavior for simpler scenarios the total time for an application should be 1 second (or say sub second) , split as -

*) 500 ms for backend processing

*) 300 ms for data transfer over network

*) (100-200) ms for UI rendering

For complex scenarios, the time can be till 3 seconds.

BR.

[former_member225463]

Hello Jagesh,

You can check your response time on the network tab in chrome.

By looking at the response time you can make your decision.

The response time also depends on the backend logic loops and all.

so better to check in the network tab by doing F12 , nce the response is completed.

Regards,

Vikash

[daniel_ruiz2]

I personally find three seconds unacceptable..

[former_member185414]

What's acceptable as per you Daniel ?

[daniel_ruiz2]

well,

usually anything over 300 ms I would ask a detailed explanation from the back-end developer.. but that's just me.. explain plan on every single query that hits the database and the SAT tool with breakdowns in functions, etc - the whole thing.

sincerely, I don't like writing code that takes less than a millisecond to run inside a browser with limited resources, having to run jsperf on every single browser testing approaches because different js-engine would perform slightly different on a .forEach vs for ++ to see a Query in ABAP running a full table scan because some developer has no idea what an index is..

there must be some real good reason for anything to take three seconds, Google for instance returns in 400 ms and I'm sure they are querying a hell lot of data.

recent case, we needed to query over a field which is a text type that was holding an XML.. it has been used some "text type thing" in ABAP where the contents of XML was broken into lines of 255 and appended over - some BAPI code would bring the contents of that field.. that itself was taking 400 ms - my question was: "why the heck this XML is not just a clob or something? - why use a BAPI that takes this long when there are performance efficient ways to write the same solution?" - I ended up with the traditional "this is how we do in ABAP" sort of answer.. pretty sure you have experienced something along these lines so far.

UI5 somehow is maturing to a point of continuous integration with performance testing, coverage, unit testing, mocking and recently a dependency injection of modules using require to only find out in many cases that "the back-end" doesn't even know what a unit test really is.. so I find a bit bizarre to have this maturity on the UI code when the core business code lack the basics.

this is my personal opinion and there's no need for you to be offended.