What's wrong with using JSONModel for data from OData services in UI5?

Question

I had to develop (with a teammate) an application which contains mainly a table with a dozen of filters, and rows loaded from an OData service with roughly 400k entries. Since we had to frequently upload the model without storing changes into the server, and we wanted a user to immediately see the results of the changes he makes, we decided to build sap.ui.model.json.JSONModel at the start of the application, which loads its data from sap.ui.model.odata.v2.ODataModel.

We found out that, in this way, the application was significantly faster than going with the direct OData binding approach, and our trick made the app work perfectly.

So, our question is: are there any drawbacks in doing what we did? Bear in mind that we both don't have much experience with the SAP Fiori world, and that in our application users don't have to write data nor create new entries in the table, they will only view data, use some filters, sortings, and download the CSV once they filtered the table.

EDIT: Here's the link for the repo containing only an mcve, where I used Northwind OData, and do problematic operations directly on the ODataModel, without using an intermediate JSONModel. The crucial operation is a filter that displays only selected item of the table: you can change Northwind OData to any service you want and see that if the number of rows of the table grows substantially, this operation requires a lot of time. Sap UI5 version used: 1.84.0

If your app is much faster that way have you thought about improving the backend? Like properly implementing paging (skip and top parameter)? — Marc
@Marc I think what Donax wants to achieve is the immediate response after filtering, sorting, etc. which is possible only if the entire data are available on the client-side. I.e. no round-trips at all. But still, there is no need for a JSONModel in that case as explained in the answer below. The only thing I question is whether users are really willing to download 400k entries everytime the app opens. — Boghyon Hoffmann
Yeah Boghyon is right, and I can't touch anything from backend. Agree that users shouldn't need to download the entire dataset every time, we also implemented some sort of prior filtering in order to at least filter out the majority of useless entries — Donax
edit: changed repo link. There was an undesired issue in the former, so please delete everything if saved something and refer only to the new repo — Donax

Boghyon Hoffmann Boghyon Hoffmann · Accepted Answer · 2020-12-14T17:05:24

I'd reconsider loading 400.000 entries at once. This roughly corresponds to 10+ MB of data load when the app launches.
About the "trick"..:

our trick made the app work perfectly.

The main difference between server-side models (like ODataModel) and client-side ones (like JSONModel) is that server-side models are aware of the query specification implemented by the backend service and thus can let the client (UI5) optimize the runtime behavior, while writing less code (often declaratively), and on top of the client-side features. In our case, ODataModel also supports client operation mode:
```
"models" : {
  "": {
    "dataSource": "myODataService",
    "settings": {
      "defaultOperationMode": "Client"
```
This will also load all entries at once for the table without having to use an intermediate JSONModel. Sorting, filtering, etc. will all happen on the client side. But again: the operation mode should be selected depending on the amount of data, target users, devices, and use cases.

Since ODataModel even supports exporting data to another format, I see such intermediate JSONModel as a pure overhead when dealing with data from an OData service.

What's wrong with using JSONModel for data from OData services in UI5?

1 Answers