71–80 of 123 posts
Firebase is not meant to be a backend for any Web app. It is a special tool for specific problems. If you just use it without evaluating if it is a good fit for your problem then you'll certainly run into a wall.
I loathe Googles various scaling limits. "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.
I loathe Googles various scaling limits. "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.
I had to increase our quota of layer 7 load balancer backends recently on GCP, submitted the request and the quota was increased within minutes. YMMV though, I guess?
Earlier quoted context omitted.
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?
JWT claims are strictly meant for JWT. I don't know how or why they would work with Facebook login, but if you need to support Facebook/Google login for users in addition to JWT, you can still implement claims/roles. You just need to create a collection for users in firebase that stores claims for all users. Protect it with security rules and then this collection to power security rules for other collections. Somethi…
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…
We were using Firebase for simple read-only queries and our dataset wasn't changing much, so statically served nested JSON files/folders were a great substitute.
In case it helps anyone else out, here's the script that automated the creation of those files from a Firebase data dump: https://github.com/zackbrown/firebasic
Nothing beats Django and the Django Rest Framework. In my opinion, it's easier to code a RESTful API in Django than to configure a 3rd party service.
Earlier quoted context omitted.
What was your decision for REST over GraphQL?
GraphQL requires you to know upfront what you want to receive. You can't for example receive data for a menu with submenus with undetermined level of depth. You can hack your way around the problem, but it's ugly. Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company?
This is similar to what I would have to do server side if I were using SQL to get the data and then processing it to return a tree in JSON.
If I know how deep the tree will be (and it is only two or three levels) I query it directly with graphql