Batching in PnP Core SDK

[s-KaiNet]

By default batching is supported for Load*, Get*, Add* and many other methods. However there are some methods (let's call them "extension methods") where the batch is not supported (actually it can be supported, but it's not implemented). For example GetByTitle, GetById, GetByServerRelativeUrlAsync for ListCollection, for Web it's pages API, syntex and some others. There are other "extension methods" in different objects without corresponding batch support.

As a contributor, If I need to add batching support for, say, Lists.GetByTitle(), I should introduce 4 additional methods - sync/async, with Batch parameter/without Batch (using the default one). If we have 10 "extension methods" it will be 60 method definitions (2 "regular" sync/async and 4 "batched" for every method), which is a bit tedious task to do. Moving forward with library growth, the number of "extension methods" without proper batch support will also grow. As a result, when compared to SP CSOM, PnP Core SDK might send a lot more HTTP requests.

I'm not sure whether it's a real issue or not, just thinking out loud. What if we can implement "implicit" batching (for example through the configuration setting, or with a parameter when creating a new instance of PnPContext), when all requests are batched by default and only executed explicitly with Execute? Meaning that no matter which methods you are using - Load, Get, GetByTitle, etc. they all will be added to the default batch. In that case we don't have to implement corresponding Batch* methods for every "extension method", but instead check some flag in code and decide, whether a request should be executed or added to a batch instead. Some requests cannot be batched, thus will be executed immediately. Will that make sense?
I know it's not possible right now without lot's of breaking changes, but may be just thinking about the future.

[jansenbe]

@s-KaiNet : you're absolutely right that for some methods we still need to foresee the batch equivalents although batching does not make sense in each and every scenario. Writing is indeed tedious and can be time consuming but it provides the user with a clear option to choose whether they go for batching or not. "Implicit" batching is something I personally think will be confusing for developers as the developer has no idea whether the request will be executed immediately or later on. When the method returns data then a developer each time has check if the data is there or not (when batching is used). If we would do this then we should do it like CSOM does and all calls are added to a batch until Execute is called...but then our API is not so fluent anymore.

Thanks for raising this idea @s-KaiNet , at this moment I'm not (yet) convinced we should make such a fundamental change, but definitely want to hear what others think. As this would be a breaking change it anyhow, like you've mentioned, would be something for the next major version (2.x).

[s-KaiNet]

Yeah, it's more idea to think about. I agree that in case of implicit batching it will be more CSOM-like (maybe I just still thinking in a CSOM-like style :)).

I have a side question though - as library contributors, should we always provide additional Batch* methods for all "extension methods" we add? It definitely makes sense for CRUD operations, but for things like GetByTitle, GetBySmth etc.?