Thank you Doug for sharing this....most helpful.
On Friday, November 6, 2015 at 6:55:11 PM UTC, Doug Thompson wrote:

Just a very general note perhaps, and to share our own experience. We
ended up deciding to do the following:

- We created a single Firebase instance
- This allowed us to locate all of our user information within a
single instance
- For each user, we create a node
- For each user we create a separate "user record" in which we record
the node for which they have access
- We use security rules to control access to that node

The security rule looks something like this:

"rules": {
".read":
"root.child('users').child(auth.uid).child('accessNode').val() === true",
".write":
"root.child('users').child(auth.uid).child('accessNode').val() === true",

To summarize the challenge we had and the thinking about separate vs
single Firebase apps:

- If you create separate instances of Firebase, this gives the benefit
that you can very clearly partition the instances and clients
- But it makes shared structures more difficult. In particular, how do
you "stand up" a new instance, how do you aggregate data across multiple
instances, and do you store user or analytics data in as many separate
places as you have clients

We felt there was efficiency in realizing that the Firebase authentication
and permissions are incredibly robust. And because Firebase is entirely
based on URLs, we could keep everything within one Firebase app while
assigning the user to their own node to which they have permission.

Not sure if this is helpful, but we spent a lot of time thinking about the
long-term trade-offs between separate apps vs a single one, and a single
one wins hands-down, especially because of Firebase security and rules.




On Thursday, 5 November 2015 20:04:35 UTC-5, sotu...@gmail.com wrote:

Hi. I'm seeking some help please on how best to construct an app for
multiple customers.
My app is up and running but I am using a url for one customer as a
constant (e.g FBURL + '/' + customer).
I have a crud service which initialises with a reference to the url. This
works well.. e.g.

app.factory('Item', function ($firebase, $firebaseArray, $firebaseObject, Ref, Auth) {

var items = $firebaseArray(Ref.child('items'));

var Item = {
all: function () {
return items;
},
create: function (item) {
return items.$add(item).then(function(ref) {
return ref;
});
},
getRec: function(itemId){
return items.$getRecord(itemId);
},
getObj: function(itemId){
return $firebaseObject(Ref.child('items').child(itemId));
},
update: function (item) {
return item.$save().then(function(ref) {
return ref;
});
},
delete: function (item) {
return items.$remove(item);
},
};

return Item;

});

The problem is how to adapt this for multiple customers. Ideally, this <https://groups.google.com/forum/#!topic/firebase-talk/vGa0oX7NLZk> is the structure i favour, but how to set the url to the customer node as they startup.

I was also thinking about a separate firebase for each customer, but how to deploy single code base to multiple firebase (in automated fashion).


If any one can help please (with code examples)


Thank you. Sola




--
You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
To post to this group, send email to firebase-angular@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/f36fe9de-2ed4-4ef0-99d9-10fdc292e7cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 3 | next ›
Discussion Overview
groupfirebase-angular @
postedNov 6, '15 at 1:04a
activeNov 9, '15 at 8:32p
posts3
users2

2 users in discussion

Sotudeko: 2 posts Doug Thompson: 1 post

People

Translate

site design / logo © 2021 Grokbase