61–70 of 123 posts
What? I use claims in JWT with firebase and it works like a charm.
I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard…
1) Relational databases are more flexible: you model your data according to the actual "relations" between them, instead of how you want to query them. This makes it easier to add new views/queries to your application.
2) Joins are necessary
3) In a very short time, you need complex authentication logic and it is very hard to do it without looking at the requested (and related) data directly. Best way to do this is a good-old rdbms + server app
4) Moving more logic from servers to clients forces you to be more careful about client versions, duplicate logic among different clients (iOS, Android, Web, Dashboard)
(deepstream employee here) despite its flaws, Firebase has some great ideas, e.g. its permission language that strongly inspired us when building https://deepstreamhub.com/ . But there are some aspects, many mentioned by the OP that send us down a different route: - Serverless is a great goal, but only works for low complexity apps. We've designed deepstream explicitly not to take the server away, but as a layer that…
As a firebase user, what would be the easiest path to map my multi-nested firebase DB (like 'chatrooms/room1/msgs/msg1`) structure to deepstream? Since I think DS doesn't support more than one level of nested data. Is there an easy way?
Earlier quoted context omitted.
Iterating would require me to first get atleast a 'shallow' list of keys for that node. But even that one REST query for shallow list of all keys crashes their server instance. I am not even sure how I should get keys for all my user nodes anymore. I tried doing it from an offline JSON backup they generate. But that one giant 100GB+ JSON is impossible to parse with any available tools.
Hmm. Congratulations, you've nerd-sniped me this morning! This sounds like a classic use case for a streaming parser. The data is a mile wide and an inch deep, so at any point the memory requirements should not be too high. What do you want to do when you've parsed it? Insert it into a real database? Iterate over it? Would simply turning it into a list of user IDs one per line suffice?
{
users: {
"userid1": {...},
...
},
...
}
But jq fails silently after 12-24 hours of processing. I am still researching this in free time.
If I can just get the keys (like "userid1") I can do the rest from firebase itself.
Earlier quoted context omitted.
As a firebase user, what would be the easiest path to map my multi-nested firebase DB (like 'chatrooms/room1/msgs/msg1`) structure to deepstream? Since I think DS doesn't support more than one level of nested data. Is there an easy way?
deepstream has a concepts of records, similar to individual documents within an object oriented database. Each record can contain any arbitrarily nested datastructure
Also, if I want to maintain a list of records (say list of chatrooms). I see that I will have to use the "Lists". But I think I read somewhere that the size of that list cannot exceed some limit. Is that true?
Thanks!
> You can’t easily add claims (groups, roles, feature toggles, etc.) to user’s json web token, meaning you have to create and supplement each authentication with a call to the Real-time database. What? I use claims in JWT with firebase and it works like a charm.
Earlier quoted context omitted.
Hmm. Congratulations, you've nerd-sniped me this morning! This sounds like a classic use case for a streaming parser. The data is a mile wide and an inch deep, so at any point the memory requirements should not be too high. What do you want to do when you've parsed it? Insert it into a real database? Iterate over it? Would simply turning it into a list of user IDs one per line suffice?
Hello. The JSON dump looks something like this: { users: { "userid1": {...}, ... }, ... } I have tried jq stream parser to split the big dump into files like: - users.json - chatrooms.json - ... So I can then work on individual nodes. But jq fails silently after 12-24 hours of processing. I am still researching this in free time. If I can just get the keys (like "userid1") I can do the rest from firebase itself.
You could to the splitting yourself (it's just plain text) and create multiple files whose contents is just an array in the format:
```
[
{},
...
]
```
Then you can use JSONStream to load each of those files individually and map/reduce on the contents.
"You need to ask a Google person to scale further, but hey we're Google and we do everything we possibly can to avoid human contact." Bleh.
> You can’t easily add claims (groups, roles, feature toggles, etc.) to user’s json web token, meaning you have to create and supplement each authentication with a call to the Real-time database. What? I use claims in JWT with firebase and it works like a charm.
are you adding custom claims to the core firebase user or as a custom jwt/additional user object? can you have a user signed in with facebook and assign a "experiment1=b" claim to it?
``` ".read": "auth != null && (root.child('users').child(auth.uid).child('claims').child('isAdmin').val() == true)", ```
This security rule will lets users read data only if their account is present in `users` collection and has `claims.isAdmin == true`. I did not test the above snippet but I have something very similar working in a project already.