I find that the current API (esp, thanks to @ed7coyne refactoring & testability) strike a good compromise between user facing usability and modularity for downstream like the modem.

We chose this compromise because ongoing tension between using modern C++ idiom to make it friendly to build downstream program (like the modem) or following https://www.arduino.cc/en/Reference/APIStyleGuide and make it friendly to the lambda Arduino user, the discussion on #93 is a good illustration of this.

I'd like us to iterate on the current design to create 2 API surfaces:

1. an Arduino-friendly 'layer' with the following properties:
   • only 1 top level type, exposed as a global Firebase object.
   • only basic type (int, float, String, bool) as arguments and return values, no stl type or pointers
   • stateful (only one operation at a time)
   • optional error handling (exposed thru boolean method: connected(), success(), failed() on the main object).
   • compose well with existing Arduino abstraction: Client
   • exposed as one dependency.
2. a C++ friendly 'layer' with the following properties:
   • follow modern C++ best practice
   • strict and verbose error handling
   • leverage heavily memory management of the STL and built in containers
   • mockable and testable
   • decouple transport types from the firebase protocol implementation and its payloads.

I think that with #90 we're very close to 2. but I'd like to work on building 1. on top of it: as part of #80 #81 #82.

Let's discuss it :)