How to store and handle (multiple) database connections?

[Domiii]

I am guessing this is part of more complex and already on-going discussions related to best-practice (such as #278 (?)), but I am rather curious how you guys deal with this sort of scenario:

Let's say I have multiple database connections and multiple HOCs referencing each. Now a lot of questions are popping up. I am not sure where to even place the database instances, since I am rather uncomfortable placing complex objects of unknown structure in my stores, since some database connection objects are rather complex and even contain cache (firebase, the DB that I am currently working with, being such a candidate). Since one major approach of dealing with firebase seems to mirror all that cache into the store, it would certainly not be a smart move to have both copies of the same data in the store, for so many reasons.

This makes me think that all database connection/app objects (which, again, also might contain its cache) should be managed separately in some sort of global variable, parallel to the store, as we would have done in the good old days anyway. That of course is quite evil.

I am wondering: Does anyone have a more specific solution to this scenario?

1. Where should I store the database connection objects? store? global? any other options?
2. Should I create separate init and CRUD actions for each connection, or should there only be one set of actions, each requiring the database connection as first argument? (this issue specifically seems to be covered by RFC: Reuse complex components implemented in React plus Redux #278, but I am curious about current real-world scenarios nonetheless)
3. Should each action be passed individually or would it be Ok to pass a sort of "manager" or "service" that is responsible for and provides all actions that can be performed on one complete path (or table)?

[markerikson]

The standard approach for managing "connection"-type objects, such as websockets, is to put them in middleware. That way they have access to actions coming through the dispatch pipeline, and can dispatch actions themselves.