Are there any calls of the Nextworld API which should always be made with "createContainer": true" and "commitContainer": true? Creating a H/D record perhaps? Others?
I’ve reviewed the NATE development considerations help topic on this and understand the trigger timing comment, but my general thought right now is if you’re creating or modifying a document which will cause a lot of activity in other documents, you should probably do it in NATE; otherwise try to avoid it if possible - is that reasonable or would there be a better rule-of-thumb in this space?
I would advertise always using "createContainer": true" and "commitContainer": true. NATE containers are almost always helpful for data integrity and error handling. The only reason you would NOT want to include those flags is if you’re chaining multiple requests; only the first needs to create the container and only the last needs to commit it, all others in between can reuse the same container.
Thanks @brendan.b - is there much of a performance penalty incurred by doing that?
I was honestly not expecting as definitive of a response as that. When you create a new logic block, by default the Use NATE Container checkbox is false, so if my understanding is correct, that means background task logic blocks running in the background, by default, don’t run in NATE.
So I’d like to understand further why that setting operates that way on logic blocks if possible.
We’ve gone back and forth over the years on the Use NATE Container flag’s default value on Logic Block Definitions. We originally had it set to default = true to try to provide behavior parity between background task LBs and the UI, but then there was a few significant use cases where it was more beneficial to have it off (IIRC the background tasks were processing such large volumes of data they were hitting the pending record count limit on the container).
So I would say use a container if:
You want the delayed trigger / action block behavior to reduce chattiness of how often they run
You have an HD structure with some form of logic block
You want behavioral parity with the UI experience
If you are going to use a container, and have multiple rest calls back to back that can/should be in the same container, reuse the container and commit it on your last rest call like Brendan suggested. This will save the unnecessary overhead of the container commit occurring every rest call.
Don’t use a container if:
You’re going to be processing 100s of thousands of records in the same container and you might hit that pending record limit.
You don’t care about any of the above and want to save a bit of overhead.
I’m sure there are points that I’m missing, but that’s my baseline assessment.