There is a way to cache data in memory.. I don't know why this isn't documented: https://stackoverflow.com/questions/38423277/does-firebase-c...
[deleted]
Why I’m dumping Firebase for Web
11–20 of 123 posts
Re: Why I’m dumping Firebase for Web
#12I used with Firebase a while ago, it was quite pleasant to use initially.
I think that all these SaaS/BaaS services do speed up development initially but they slow things down in the long run. I had the same issue with Amazon Elastic Transcoder (for videos) and SNS; once you need to split out different environments (development, staging, production) and then scale to support more regions and start splitting up jobs into more streams; it can get really difficult to the point that you wish you were running your own service instead.
Re: Why I’m dumping Firebase for Web
#13What are you moving to as an alternative?
I'm moving to a combination of 2 things: [1] Cosmos DB for data storage, and [2] Service Fabric for the things that require real-time collaborative logic. An example of what I mean by #2 is things like real-time discussions where content pops in dynamically.
The big problem for me using a serverless architecture was constantly having to bend over backwards with the security model of firebase to accomplish things that are very simple when you have a layer of business logic under your own control on the server between the client and the database. Once the client can write whatever they want to the database, every single operation becomes an order of magnitude more difficult to develop as you imagine what ways the client could mess with you, and develop security rules to prevent that. The result-- and this was the dealbreaker for me-- is designing the backend data structure around security, instead of designing the backend data structure around the vitally important goal of supporting your business use cases.
In the end I decided it's better to just pony up and make a server. Service Fabric, and particularly the distributed actor model, gives me the realtime functions and reliability I want for my use cases without making me administer servers.
[1] https://docs.microsoft.com/en-us/azure/cosmos-db/introductio...
[2] https://azure.microsoft.com/en-us/services/service-fabric/
Re: Why I’m dumping Firebase for Web
#14Earlier quoted context omitted.
I'm not the author, but I moved back to good old REST after flirting a bit with GraphQL.
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?
Re: Why I’m dumping Firebase for Web
#15http://phoenixframework.org/ actually has a built in websocket layer called channels. (its the inspiration for action cable and django channels) . Unlike deepstream, or socketcluster, it has a longpolling fallback as well as multi node clustering. Its a shame more people don't realize what a gold mine of a piece of technology it is.
Dokku implementation for any Linux server hosted locally or in the cloud. Not affiliated just really like the product.
https://ashleyconnor.co.uk/2016/03/06/deploying-a-phoenix-ap...
Re: Why I’m dumping Firebase for Web
#16I never actually deployed this, so I don't know how it would have worked with lots of users, but when I was writing a game that required "secret sauce" my plan was to have a "server" connect as a privileged user- clients would submit their proposed moves to a write-only queue that was only readable to the "server" which would do a rules-check and update the game state as necessary.
Re: Why I’m dumping Firebase for Web
#17Earlier 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?
> 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?
http://graphql.org/learn/schema/#interfaces
searchPersonOrCompany(name: "abc") {
... on User {
first_name
last_name
}
... on Company {
business_name
}
}
GraphQL can't return depths without you querying for it unless one of the field is a JSON blob.. but at the same time, I like that it does that.
In your example of menu w/ submenus, I think I would prefer to load the first 2 level, then preload level 3 when level 2 is activated, and preload level 5 when level 4 is activated, and so on.
Apollo makes this quite easy.
Re: Why I’m dumping Firebase for Web
#18Has anyone here used gun extensively? https://github.com/amark/gun it seems to position itself as a competitor to firebase, and wouldn't have many of the issues mentioned in the OP
Re: Why I’m dumping Firebase for Web
#19Has anyone here used gun extensively? https://github.com/amark/gun it seems to position itself as a competitor to firebase, and wouldn't have many of the issues mentioned in the OP
Wow, this is the exact thing I've been thinking of writing, but so much better. I'm so glad this exists, brb trying it out right now
Re: Why I’m dumping Firebase for Web
#20I stopped using firebase DB about a year back. Now I prefer:
1) API backend using Google Cloud Endpoints deployed in GKE. Still using firebase Auth.
2) React SPA served from firebase hosting. Using FirebaseAuthUI
One thing I continue to be astonished about is how difficult it remains to build a real apps (ssl, auth, persistence, packaging, deployment) as a one person team.