Creo que las funciones están hechas para lidiar con muchos panoramas, pero que hay 3 casos a destacar:
- Lidiar con los triggers de firebase.
- Implementar código para conectarse con APIs o para exponer endpoints.
- Alambrar los triggers con las APIs.
La idea es que cada una de estas cosas esté desacoplada y pueda ser portable (en un subtree de git preferiblemente). Para lidiar con esto, tratando de mantener simple la estructura de carpetas, creo que debería de implementarse así:
functions/src
….productos-fn
….woocommerce-api
….local
……..woocommerce-cn
Y aquí van los porques:
productos-fn debe contener todas las cosas que van hacia adentro de la aplicación. En español, lidiar con los triggers y callbacks del módulo productos, en este caso. Así, ambos subtrees pueden ser portables y utilizarse en otra app, sin mas dependencias que las librerías que tenga.
woocommerce-api es una implementación que mira hacia la API. Quiere decir que debe definir las interfaces para comunicarse con ella e implementar las funcionalidades para ejecutar lo que sea que tenga que ejecutar, pero también tiene que ser portable, sin estar acoplada a la app.
Finalmente local/woocommerce-cn es una implementación local y es la que hace el acople entre woocommerce-api, productos-fn y cualquier otra parte de la app que esté involucrada. En español woocommerce-api y productos-fn están desacoplados uno del otro y no se necesitan mutuamente para funcionar y local/woocommerce-cn implementa todo el código que hace el acople y que define las dependencias. Como parte de la implementación local no hace falta que sea portable y es allí donde puede lidiarse con cualquier cambio en alguno de los otros «módulos» que necesite.
Sí. Es más código, pero a la larga es más mantenible y va a permitir que los módulos, y la aplicación misma, evolucionen separadamente sin ponerse palos en las ruedas mutuamente. La clave es que se puedan definirse y respetarse las interfaces de cada módulo, para que esa independencia se mantenga.