Clarification on number of calls to BE's from JSDO - Forum - Mobile - Progress Community

Clarification on number of calls to BE's from JSDO

 Forum

Clarification on number of calls to BE's from JSDO

This question is answered

Hi All 

We are using the JSDO in our application which is working okay but seems quite chatty and i want to make sure we are no making unnecessary requests to the back end.

When we use it with our grids or our invokes we essentially do the following:

Create a datasource - This makes an 'options' call to the Catalog and then a 'Get' call to the catalog

Read the datasource - This makes a 'Get' call to the BE resource to get the data

If its a KENDO GRID it also makes a count request which is again formed of an 'options' call and a 'PUT'

So using this with a Grid, (on initial load) results in 5 calls or with an Invoke results in 3 calls.

See example from a GRID

Does this sound correct?

Thanks

Christian 

Verified Answer
  • Hello Christian,

    The behavior that you are seeing is expected.

    The options request happens automatically by the web browser for cross domain requests as part of preflight request.

    Related link: developer.mozilla.org/.../CORS

    The request to the catalog would load only once for the session.

    The GET request for the data would happen whenever there is a READ.

    The PUT request (invoke request for count) happens because server-side processing is used and the Grid needs to know the number of records for paging.

    If required, it is possible to use a custom filtering (instead of the JSON Filter Pattern (JFP) as mappingType) and calculate and return the count as part of the READ.

    I hope this helps.

All Replies
  • Christian,

    That is exactly the behavior we see in our experience. I believe the thinking behind all the OPTIONS calls is to proactively prevent the application from making calls to non-existent endpoints or from making malformed requests to endpoints. Actually, preventing malformed requests is probably based on the catalog itself. Maybe someone from the JSDO team can chime in. It seems like they are implementing part of the HTTP standard/spec that very few people have used so far.

    For us, the OPTIONS calls take about 50ms, which is acceptable if a page needs to make a few of them as it loads, but it is non-zero. So there is a impact to the site's performance, albeit a small one.

    Tim

  • Hello Christian,

    The behavior that you are seeing is expected.

    The options request happens automatically by the web browser for cross domain requests as part of preflight request.

    Related link: developer.mozilla.org/.../CORS

    The request to the catalog would load only once for the session.

    The GET request for the data would happen whenever there is a READ.

    The PUT request (invoke request for count) happens because server-side processing is used and the Grid needs to know the number of records for paging.

    If required, it is possible to use a custom filtering (instead of the JSON Filter Pattern (JFP) as mappingType) and calculate and return the count as part of the READ.

    I hope this helps.

  • I would like to add that it appears the JSDO only calls the catalog once on the first request for that BE and subsequent requests the catalog is not called.