111–120 of 123 posts
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...
I implemented the solution in a Firebase wrapper and it works great.
Anyway, Google is solving this in JS by implementing persistence.
How do GraphQL subscriptions compare for providing realtime functionality?
That said, the idea is similar. You subscribe and unsubscribe to data. Some callback is called when data is updated.
I have clients with apps that are pushing the boundaries of Firebase. I have strongly suggested the move to Azure or Amazon "serverless" - Azure Functions or Amazon Lambda. I get strong pushback due to "cost and complexity" concerns. I respond that of course "real" development and operations is going to be more complex and expensive than the "toy" proof-of-concept they build with Firebase. But this has been an issue…
* Any non-trivial application can explode in complexity quite quickly, even with well-designed data boundaries and code flows * The human brain is incapable of managing said complexity in any effective way * We must therefore break this complexity into consumable pieces that fit inside our heads * Which means redesigning those data boundaries and data flows, in order to make them fit in our heads, which inevitably moves the complexity around the system
RAD tools HIDE all that complexity but the moment you need to move it, you can't. So you end up having to re-implement.
I am using Firebase for an app I do not expect to ever exceed a few thousand users - it is an app for a local business that is quite popular, but limited in geographical scope. So it's a good choice.
I wouldn't pick it for larger apps whose potential growth is not so limited. I'd take the hit up front to properly build an architecture that can scale (but doesn't, at first, per Martin Fowler).
Firebase taught me, for a B2B2C kind of app: 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 rel…
> 2) Joins are necessary > 4) Moving more logic from servers to clients forces you to be more careful [...] Back to the very old architecture of client-server-database instead of client-database that was proven dumb long time ago. The client-server-database architecture was happily ditched by the crowd that builds dynamic websites and calls them "web applications", so now everybody rediscovers that it actually is a p…
I'm personally thankful the nosql hype has finally subsided, and everyone recognizes it for what it is, a tool in the box. Not everyone has made that realization yet, as other posts in this thread indicate.
Server pushing data enables some really useful things, the archetypical example being online chat. Adminless backends are also very attractive to a lot of people, in particular front end devs who just want to build, not do a poor (insecure) job admining servers. I personally lament this "everyone's a server admin" culture we have come into in recent years.
But those innovations aren't enough to make up for the deficits the author, and many here are describing. Like others have said, use Firebase for what it's intended, and when you really need to scale, be prepared to roll your own solution.
Your feedback is both fair and something we're diligently working to fix. In response to each of these points:
1. [Local testing only works for HTTPS]. For better or worse, our product is built in layers. There's the core Cloud Functions product and the "for Firebase" add-ons. You can already see some public changes we've made to the core Cloud Functions emulator that include some support for event-handling Cloud Functions as well as improvers in debugger support. We definitely want better "in house" support and are in the user testing stages of some generational leaps in local testability with the Firebase toolchain. You can reach me at my handle at google.com if you'd like to be considered for some of the user testing.
2. [Debugging feels like a murder mystery]. Yes, this is another thing we are working on. Cloud Functions integrates with Stackdriver Debugging[1]. There are very real issues with the integration today. TL;DR: If you have a steady stream of requests, it will work. If not, the ephemeral instances won't be alive/unthrottled long enough to fetch watchpoints. This is a huge concern to many of us within Google and we're working hard to improve the way it works.
3. [No cron jobs]. Again, a huge feature request and a high priority. You don't need to use your own machine; you can use GAE's free tier to kick off cron jobs for you[2]. Still, a more tightly integrated solution is obviously ideal and is coming.
Closing: We take these issues very seriously. I'm sorry we don't have the solution to your problems today, though all three line up with active development on the team. We are focused on delivering infrastructure required for mature apps with high volume and mission critical traffic. Keep an eye out for our product as it crosses into generally available and beyond.
[1]: https://cloud.google.com/debugger [2]: https://github.com/firebase/functions-cron
Earlier quoted context omitted.
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…
I'm afraid I don't yet follow your problem: what's hard about having a function listen for a change in the db, performing the business logic, and updating another value?
I 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.
- completely use firebase
- completely use AppEngine
So, you would get easy packaging, ssl, deployment, infrastructure maintenance..
Has 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
Earlier quoted context omitted.
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
Just noticed this today, sorry for the delay. I'm the author, anything I can do to help out? Let me know!
Earlier quoted context omitted.
Just noticed this today, sorry for the delay. I'm the author, anything I can do to help out? Let me know!
Hey -- nice job! I have a question: is there a way to use MongoDB in the backend?
https://github.com/sjones6/gun-mongo
https://github.com/sjones6/gun-mongo-key
Anything else?