Thanks for your suggestion @Fuzzyma . The assumption is that server-side code is not sensitive to the size (as much as a web client), and as a result clients would benefit most from the tree shaking. I do see your point about the advantages of not using two different APIs for different use cases. I'll follow up with the team to see whether there are any plans for this and I'll post an update when I have more information.

I agree that size concerns don't don't apply for node. But consistency is rather important.

There is one more important factor: composition doesn't need monkey patching. A good example is the package fireway. It patches the methods from this package to allow for dry runs and to track stats. However, if those methods would simply be functions, a wrapper would serve the same functionality in a way cleaner and maintainable way.

Also: I am pretty sure atm there is a lot of duplicated code between firebase/firestore and @google-cloud/firestore which probably could be reused when using compositional code.

@Fuzzyma you might find this firebase-admin discussion interesting: firebase/firebase-admin-node#1238