Multi Tenancy / Multiple Realtime Databases / Firebase Functions trigger duplication

[Shai Ben-Tovim]

Hi,

We're in the process of building a SaaS platform over Firebase serving multiple customers.

To date, we're serving a handful of customers and are achieving isolation in the RTDB by using separate "root" keys in the database.

Example:

{customerId}/orders/{orderId}...

This allows us to easily read/write to right place + protect any actions using database rules checking if the reading/writing user belongs to that `customerId`.

Also allows us to set function triggers such as:

functions.database.ref('{customerId}/orders/{orderId}').onCreate(processOrder)

That would work for any customer.

As we scale, we're considering to move to separate DBs per customer  - a feature Firebase introduced last year.

This would provide better isolation per customer and allow different DB rules + help solve potential performance problems as we grow.

One thing we haven't figured out is what to do with the function triggers. Does this mean we'd have to duplicate all of the DB triggered functions per DB/customer?

Is there a way to define a trigger on the same path {customerId}/orders/{orderId}  for multiple DBs?

Even if you disregarded the manual work required to support such a deployment, it also means we'll hit the MAX ALLOWED functions per project limit really fast.

Any input/ideas would be appreciated

Shai.

[Kato Richardson]

Hi Shai,

The manual work here wouldn't be significant. Something along the lines of:

function triggerEvent(...) { ... }

[ ...listOfDatabaseInstances ].forEach( instanceName => exports[ 'triggerEvent' + instanceName ] = functions.database.instance(instanceName).ref('/foo/bar').onCreate(triggerEvent) );

However, hitting the max allowed functions per project sounds like a concern. If there are a very large number of orgs, and what you're looking for here is multi-tenancy, you might just want to go all out and use a separate project for each org. There are some restrictions here on sharing apps between projects that could conflict (specifically you can't share OAuth SHA1 keys with multiple projects).  

If these orgs interact in some way, and share significant functionality, then you might consider a different sharding strategy, perhaps by logical area of the app rather than org. For example, perhaps user profiles and org-specific data get their own DB instance, but common "pools" that trigger events, such as your message queue or "inbox" feature are isolated onto one or two databases where triggers can run and write out to the other instances.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/00ef5ba0-25f2-451a-bcb6-11b79b9ec339%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Shai Ben-Tovim]

Hi Kato,

Seems that the Functions limitation will force to me to either:

Separate to an individual project per my customer

• Will have to duplicate provisioning efforts for each project (push notifications, analytics, etc).
• Will have to add some kind of logic in my apps that they'll know to which Firebase project to connect and authenticate with (without separating them out to individual apps on the App Store / Google Play).
• Q: Is there a limit to number of projects I can have on GCP/Firebase?

Keep one "super" project that includes all customers

• Will have logical separation of DBs (one for each customer) where "function-triggering" DB updates will concentrate in common DB instance that will:
• Trigger the function
• The function will also update the customer-specific isolated DB as part of its execution
• OR: instead of updating the DB my server logic will initiate a pub/sub message that will trigger a function that does its thing + write to the DB (IMHO, a really bad solution that masks true application logic intent in favour of Google arch deficiency).
• Q: Is there a way to define a function trigger to the underlying pub/sub (I assume) mechanism that translates a DB update to a function trigger? Can I create a "generic" trigger somehow?
• Q: is there any public roadmap to address the functions limit ? or provide a more flexible trigger that can span DB instances?

Anyways, none of these are great for me  - would be glad to hear any opinions.

Shai

[Kato Richardson]

Generally speaking, if you're running into things like the Functions cap, this is likely an XY problem. It might help to actually work through the goal here and talk about why you've settled on sharding as a solution, and specifically why sharding by tenant is the ideal solution.

> Q: Is there a limit to number of projects I can have on GCP/Firebase?

There is a limit to the number of free projects you can create for a given account, to prevent abuse scenarios. Paid projects are fairly unrestricted.

> ...my server logic will initiate a pub/sub message that will trigger a function

I don't see any advantage to calling pub/sub here unless it's cheaper per invocation in some way (i.e. if the writes are fairly large and you can skip writing to the DB).

> Is there a way to define a function trigger to the underlying pub/sub (I assume) mechanism that translates a DB update to a function trigger? 

Not that I know of, although it's an interesting idea.

> Can I create a "generic" trigger somehow?

In the sense that you could create a single code block to handle triggers from multiple DBs, yes. In that you could avoid the additional functions count, no.

> Q: is there any public roadmap to address the functions limit ? or provide a more flexible trigger that can span DB instances?

I don't know of any plans to alter the limit to number of functions you can create. This isn't currently considered a deficiency. I haven't heard of any plans to create triggers that act on multiple DBs, but it's worth putting in a feature request for.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/189227b7-d598-46ff-b118-4254870b06d9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.