31–40 of 48 posts
But is it really "realtime"? I thought something should have consistent millisecond or even microsecond latencies to be called realtime, but it's probably not possible for JavaScript application.
If you wanted to be pedantic, nothing is real-time not even what you see with your eyes due to photon latency. The word is clearly being used colloquially
My typical approach is directly logging onto fs with replaying upon restart for small projects, with fs based json store / leveldb for more demanding tasks. For non-trivial scale projects, RethinkDB is a fair choice.
How is this different from Firebase RTDB? And perhaps more importantly, does it address the scalability and consistency issues associated with Firebase RTDB? Google introduced Firestore to Firebase specifically because RTDB has limited usability for larger real world applications that go beyond "sync device state to DB". Even the offline first paradigm is fundamentally flawed in general and certainly when it comes to…
I love the idea of couchdb, but the ecosystem centers too much on pouch, which doesn't have consistent maintenance. If Ibm was smart they'd sponsor it in a big way.
On top of that hosting any of the server applications is increasingly a pain to setup/manage especially from a PaaS approach rather than an IaaS approach. IBM has only done terrible things to make this worse over time. My requirements when I started was I needed to host on Azure, and Cloudant supported that at the time. IBM of course being IBM and focusing entirely on IBM Cloud and its new name/strategy/plan every ~nine months dropped the Azure support I'm still told I need. But the constant name changes (IBM BlueMix, IBM Cloud, whatever it will be next week, IBM WatsonRain or whatever), plan changes, cheese moving, don't give me a lot of confidence in IBM's Cloud efforts even if I wasn't feeling a lot of pressure from my IT colleagues to get everything (back) into Azure. I'm almost desperate enough to build a Pouch driver for CosmosDB myself at this point.
How is this different from Firebase RTDB? And perhaps more importantly, does it address the scalability and consistency issues associated with Firebase RTDB? Google introduced Firestore to Firebase specifically because RTDB has limited usability for larger real world applications that go beyond "sync device state to DB". Even the offline first paradigm is fundamentally flawed in general and certainly when it comes to…
In-flight business objects for major airlines is probably considered scale: https://www.couchbase.com/customers/united-airlines
Earlier quoted context omitted.
In-flight business objects for major airlines is probably considered scale: https://www.couchbase.com/customers/united-airlines
that's CouchDB, not PouchDB. PouchDB is a JavaScript implementation of CouchDB.
Cloudant (API Compatible with CouchDB) has a number of case studies you can reference for production success with the Couch API/ecosystem.
Cabify - https://www.ibm.com/case-studies/cabify-cloudant
Ticket Fairy - https://www.ibm.com/case-studies/the-ticket-fairy-cloud-clou...
We.Trade - https://www.ibm.com/case-studies/wetrade-blockchain-fintech-...
Disclaimer: I work for IBM Cloud
The concept or RxDB, being able to iterate observables of your change stream, is great. Centering on schemas and typescript is as well. The broadcast channel based leader election also solved the common issue with Pouch where you can’t respond to real-time changes and update your UI if a separate tab was watching too. It’s wise of them to also support pulling data from GraphQL. I built the first version of NoteBrook…
I've been searching for something like this for a really long time (specifically in the context of mobile but web would also be great). For the last project I settled on Realm and their sync service (not entirely open source). There's a lot of things that get you 90% of the way there but surprisingly little that ticks all the boxes.
How is this different from Firebase RTDB? And perhaps more importantly, does it address the scalability and consistency issues associated with Firebase RTDB? Google introduced Firestore to Firebase specifically because RTDB has limited usability for larger real world applications that go beyond "sync device state to DB". Even the offline first paradigm is fundamentally flawed in general and certainly when it comes to…
What's the advantage of this over triggers in a relational database? Or even notify/listen in PostgreSQL? (assuming these triggers are connected to the API, of course). I guess it's probably a matter of scale, but I really don't know.
It runs fully on the client and is offline first. A listener to PostgreSQL will not work when the device goes offline.