All Facades Should Accept Bulk Arguments
Please, JFDI. It’s not actually hard: you expose, say, a Foobar method
that accepts the bulk args and loops over them to check validity and
authorization; and then it hands the acceptable ones on to an internal
oneFoobar method that does the specific work. (Or, if you have an
opportunity to improve performance by doing the internal work in bulk,
you can take that opportunity directly without changing the API.)
There are several reasons to prefer bulk arguments:
- if all your args are bulk, nobody needs to remember which ones are
- implementing your apiserver/common capabilities in bulk makes them
easier to reuse in the cases where you do need bulk args - those cases are more common than you might think – and even if you
don’t strictly need them in any given instance, that’s often just
a failure of imagination.
Consider, for example, any agent worker that deals with a set of
entities. deployer, provisioner, firewaller, uniter, probably a bunch of
others. They’re pretty much all seeing lists of entities and then
processing them one by one: check life, read some other data, handle
them. And this sucks! We really would kinda like to be able to scale a
bit: when you get 100 machines and you want to know all of their life
values and provisioning info, it is ludicrous to make 200 requests
instead of 2.
And because we already implemented a bulk common.LifeGetter you can
get that for free; and because you then implemented, say,
common/provisioning.Getter, then the next person who needs to divest
the provisioner of some of its too-many responsibilities will be able to
reuse that part, easily, in its own Facade. (And she’ll also thank you
for having moved common.LifeGetter to common/life.Getter, which you
did because you are a good and conscientious person, alongside whom we
are all proud to work.)
Next: