121–126 of 126 posts
Cool. But how is this better than Meteor for building webapps? Meteor would scale better too with Apollo.
I do not think that meteor will scale better then your GraphQL server with whatever database you want to have. With meteor you are bound to a specific ecosystem which is often a pain. RxDB does only one thing, it is a client side database. Everything else in your stack is free to choose.
Earlier quoted context omitted.
Interesting, thanks for sharing how you're doing it. Is there any mileage in doing this with triggers? I have a _very_ legacy system which needs caching adding. Rather than dig through the code to invalidate the cache every time a record is updated/deleted in 20+ tables, I am thinking that being able to listen to the SQL executed and invalidate the cache based on the tables involved would be a clean approach. But not…
Yeah I also used triggers at the start. There are 2 things that this implementation achieve over triggers. 1. Triggers have an 8000 byte limit. I ran against these limits pretty quickly 2. You need to attach the trigger each time you create a new table. With this you can set and forget
Earlier quoted context omitted.
MeteorJS tried it and failed miserably. It doesn't scale.
Wrong. This is popular anti-Meteor FUD spread by people who don't know how to use its features properly or have the engineering/computer science background to design a system to be able to manage computational complexity or scalability. In 2015, my business implemented a Meteor-based real-time vehicle tracking app utilising Blaze, Iron Router, DDP, Pub/Sub Our Meteor app runs 24hrs/day and handles hundreds of drivers…
Earlier quoted context omitted.
I think the Firebase Realtime Database and Firestore have a good model for offline and being able to have private and mutable data. It does get complex but the Firebase SDKs do the heavy lifting for you here.
Can you share more about the private and mutable data functionality for Firebase? I used them a few years back, and never really understood how to do private data without building my own ACL inside Firebase.
You do need to have you ACL data also stored in the database, which can be a hassle if you have existing ACL system already built outside of Firebase.
xrd, do you have a specific question about private data in Firestore?
Earlier quoted context omitted.
Can you share more about the private and mutable data functionality for Firebase? I used them a few years back, and never really understood how to do private data without building my own ACL inside Firebase.
Here is a couple of specific examples: https://medium.com/firebase-developers/patterns-for-security... https://firebase.google.com/docs/firestore/solutions/role-ba... You do need to have you ACL data also stored in the database, which can be a hassle if you have existing ACL system already built outside of Firebase. xrd, do you have a specific question about private data in Firestore?
In so many ways it is SO much easier to use Firebase because all the pieces are right there as compared to a DB + Server + Front End + Tooling. But, I still always worried that I would somehow leave a gaping hole in my data and not know about it.
And, I was never really sure how I can easily do joins across data without writing my own bespoke metalanguage inside Firebase. A link posted today on HN talked about XML does turn out to be good for nested data (hence the reason it is used for UIs), and it feels like Firebase being more or less JSON loses in this respect.
That's just my experiences, and I say that loving Firebase.
Those two examples made me think: Firebase removes a lot of complexity for me, but it forces me to write my own layer of complex access and DB logic which I never felt fully qualified to do, and as such, just went back to using databases with an ORM and a backend server.