Multiple models from 1 call to 1 remote data source (Banzai)

I’ve been playing with Banzai - loving it so far! I take it this is an appropriate place to ask questions and feedback about it?

I’ve setup a REST API outside of Salesforce that makes calls to a number of other systems, the thought being that I can call the REST API I have setup and have that call multiple external systems, rather than having to call multiple endpoints from within my Skuid page. The object returned has keys with results in an array from each system.

I can set up multiple models that look at each relevant part of the response (with “Path to Contents”) and use those models within my page; however this makes multiple calls to my API, which isn’t efficient because each underlying system gets hit on each call, as well as redundancy of data being returned.

Rather than use multiple models, I’ve tried to use the “outer” result object (which has the keys and arrays), but the Skuid components don’t seem to understand the array structure - for example, if I put a field editor in the page, it isn’t able to recognise there are multiple records in the array that should be displayed (i.e. the editor should repeat, once per item in the array), it just displays information from the first one.

Are there any other approaches that I’m missing that will work in the way I want it to? The only other solution I can think of is to dynamically create model records with Javascript from another Model that makes the actual call, but this feels like a hacky workaround.

Thanks in advance.

I think its too early to be offering Banzai best practices yet.  Its still in private Beta.  But nevermind.   

The strategy you are pursuing (one big API) is going to have the side effect of redundant data incorporation.  When we call a REST API - it is the API that chooses what data to send back.  We don’t have the ability to filter that data in model definition.  (Unlike SOQL or O-DATA query construction).  This means you are probably going to be better off setting up different API’s for your different data access scenarios.  Maybe build one API for each of your models. Or at least one API for each data access scenario.  This might be more work on the back end,  but I think it will make for a more performant solution in the long term. 

Let me know if you have further questions.  

Gary,

I get what you’re trying to do with your “big API”, and it makes total sense from an architecture perspective. I was under the impression that REST Models whose Query Method performed a GET request to the same URL would all be consolidated within one actual HTTP request, with the HTTP response then being handed off to each Model for each Model to “drill down” to the desired section of the outer response, as defined by the “Path to Contents” property. (POST Requests would not be able to be “consolidated” because different POST data could be sent in the body of the requests made by each Model, but for GET’s with exactly the same URL, the REST Models should be making only one HTTP Request.) The use of the “Path to Contents” property would be essential here in order to set the base of each Model to a particular nested Array or Object within the outer payload.

If identical GET requests made by different Models are not being uniquely identified such that only one final HTTP request is made, then this would be a “bug” with Banzai. I’ll test myself to see if this is working and get back to you.

Zach

Hi both, thanks for your feedback. And FYI - what we have built is just a proof of concept to explore a few things.

@Zach - based on your comments, I had another look at the page and opened the dev console. It looks like there is the one remote call, and this seems to match what you describe.

On our API endpoint however, we register 3 requests (one for each model we’ve setup). So this might be something on the controller side? I’ve tried adding debug logs in Salesforce to my user but it doesn’t seem to trip for the remote call or any of the callouts.

It’s entirely possible I’ve set something up wrong, or in such a way that the logic in the controller isn’t working as anticipated; I can share the page config if need be, but would rather do it off of this community.

Finally, for reference, here’s an idea of the structure of the payload coming back from the API (a sample with the focus on ease of readability!):

{<br>&nbsp; "key1" : [<br>&nbsp; &nbsp; {"prop1" : "value1"},<br>&nbsp; &nbsp; {"prop1" : "value2"}<br>&nbsp; ],<br>&nbsp; "key2" : [<br>&nbsp; &nbsp; {"prop2" : "value3"},<br>&nbsp; &nbsp; {"prop2" : "value4"}<br>&nbsp; ],<br>&nbsp; "key3" : [<br>&nbsp; &nbsp; {"prop3" : "value5"},<br>&nbsp; &nbsp; {"prop3" : "value6"}<br>&nbsp; ],<br>}



@Gary The one network request you’re seeing in the console is actually deceiving — by default, Skuid aggregates all requests to external sites and proxies them through Apex, which is necessary for multiple reasons, the most important being authentication and cross-domain restrictions. Typically if you’re querying a few REST Models, these requests will all get sent up to the Apex proxy in one network request, at which point you lose visibility into what’s going on, until it hits your external servers, but if there were in fact, say, 3 distinct initial requests, then there will be 3 distinct HTTP requests made by the Apex proxy, regardless of whether these requests get sent up to the Apex proxy in one HTTP request.

So the issue is still there :slight_smile:

Gary,

As of the next release of Banzai, this will be fixed — external Model requests will be treated as “identical” HTTP Requests if:

1. The request method is GET, and has no body / data payload.
2. The Model Service used to connect is identical.
3. The URL is identical.
4. The request headers are identical.

I have tested with an API endpoint returning a result very similar to yours, and verified that only one HTTP Request is being made to the target endpoint — 3 separate Models, each going to the same URL, but with 3 different “Path to Content” settings.

Thanks Zach! Hope I helped with the Banzai release :slight_smile: