reactfire
differential-dataflow
reactfire | differential-dataflow | |
---|---|---|
17 | 14 | |
3,477 | 2,473 | |
0.5% | 1.6% | |
4.2 | 8.3 | |
20 days ago | 4 days ago | |
TypeScript | Rust | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
reactfire
-
Angular Fire equivalent for React?
ReactFire
- How can I use Firebase to monitor live circuit tripping in a train IoT project?
-
Can't call Google Cloud Function from a react app. I get googleauth.js:17 Uncaught Error: Cannot find module 'child_process' in my browser's console
Are you using Firebase? If not, you probably should. You can call functions (with Auth) from your react app. There's a framework you can use to help: https://github.com/FirebaseExtended/reactfire
-
Convex vs. Firebase
I was an early developer at Firebase. I think we made Firebase so easy to use and never spoke on about the technicals that the whole software ecosystem now underestimates the complexity involved. I see various Firebase competitors asserting various "mistakes it makes" without really understanding what it delivers, which is understandable because we never marketed it like that because we spoke only about how it can help you build easier.
The idea that n queries instead of a join is slow is not as true as you would think. Firestore supports streaming and pipelines at its core, and can reuse cache across operations. At the end of the day, the data goes over a narrow network channel. If you can saturate the channel, and don't leave any gaps, what's the performance difference if the data comes from a single query or many that are back-to-back. The data is transferred to the client either way. Both Firebase databases are pipelined, so this "many round trip" argument is not a decent argument if the client can issue the queries without waiting for responses (such as the code in this article).
The other is consistency levels and correctness. I constantly see devs call Firebase an eventually consistent database which is wrong, its causally consistent [1], and this makes a huge difference when trying to do OLTP. The offline capabilities are built on the consistency primitives, and it's the only way it can work. So while this convex article is banging on about "End-to-End Correctness Philosophy", they miss the most important quality of correctness, and if they are not careful, will miss the required engineering, and then be unable to deliver an offline cache over real-time streams. I see this playing out with Supabase, I warned them personally before they got into YCombinator that what they were building was not causally consistent. Since then, they have had to rearchitect their real-time features after shipping them. (I have not reviewed their latest design yet so I have no idea whether they have it right yet).
Many things sucked about Firebase. The bespoke security rules and the lack of views. So Convex is on the money shipping functions on the backend. I think Supabase is shipping competitors' mistakes with row-level security language. Personally, I think Firebase's mistakes can be fixed with the addition of an open-source Firebase server [1], as the clients are already open source and the mistakes are all to do with just the server. The real tech was always in the clients anyway (offline cache, connection management, operation queues).
It will be interesting to see if building expressly for React is a good idea. Firebase shipped many adapters, like https://github.com/FirebaseExtended/reactfire, using the "thin-waist" principle of not over-fitting. But Javascript technology moved from callbacks to async while Firebase was in the field, so the current API is not now idiomatic. But convex is setting itself for even more ecosystem fragility, what if React changes API or falls out of favor? This is a big risk! I hope they can roll with whatever happens!
[1] https://observablehq.com/@tomlarkworthy/redis-backend-1
-
Do you have to use an ODM for firestore?
Since you mentioned you're also using React, we have a React specific library (ReactFire) that also helps out quite a bit.
-
Get current user firestore database
Use ReactFire! It's our official library for React and Firebase. It has a bunch of useful hooks that probably handle most of the actions you are looking to do.
-
Intro To ReactFire v4 - Login, Logout Create Account And Protected Routes
This is a quick walkthrough of a code example using ReactFire v4 in an application. The application supports login, logout, create an account, and protected routes. We also walk through two approaches for protecting routes since the AuthCheck component that existed in v3 no longer exists in v4 of ReactFire.
-
Is state management (React Context, Redux) really needed for Firebase?
FWIW check out ReactFire, it gives you hooks and context for Firebase. Will likely feel more natural than using the vanilla platform-agnostic SDK.
-
React Query + Firestore = ❤️
reactfire
differential-dataflow
-
We Built a Streaming SQL Engine
Some recent solutions to this problem include Differential Dataflow and Materialize. It would be neat if postgres adopted something similar for live-updating materialized views.
https://github.com/timelydataflow/differential-dataflow
https://materialize.com/
-
Hydroflow: Dataflow Runtime in Rust
I'm looking for this but can't find it, how does this project compare to differential dataflow?
As a sibling commenter mentioned, it's built on timely dataflow (which is lower-level), but that already has differential dataflow[0] built on top of it by the same authors.
How do they differ?
[0]: https://github.com/TimelyDataflow/differential-dataflow
- Using Rust to write a Data Pipeline. Thoughts. Musings.
- PlanetScale Boost
- Program Synthesis is Possible (2018)
-
Convex vs. Firebase
hi! sujay from convex here. I remember reading about your "reverse query engine" when we were getting started last year and really liking that framing of the broadcast problem here.
as james mentions, we entirely re-run the javascript function whenever we detect any of its inputs change. incrementality at this layer would be very difficult, since we're dealing with a general purpose programming language. also, since we fully sandbox and determinize these javascript "queries," the majority of the cost is in accessing the database.
eventually, I'd like to explore "reverse query execution" on the boundary between javascript and the underlying data using an approach like differential dataflow [1]. the materialize folks [2] have made a lot of progress applying it for OLAP and readyset [3] is using similar techniques for OLTP.
[1] https://github.com/TimelyDataflow/differential-dataflow
[2] https://materialize.com/
[3] https://readyset.io/
-
Announcing avalanche 0.1, a React- and Svelte-inspired GUI library
differential dataflow which is used to power materialize db
-
Differential Datalog
It's partially inspired by Linq, so the similarity you see is expected.
It's not really arbitrary structures so much, though you're mostly free in what record type you use in a relation (structs and tagged enums are typical, though).
The incremental part is that you can feed it changes to the input (additions/retractions of facts) and get changes to the outputs back with low latency (you can alternatively just use it to keep an index up-to-date, where you can quickly look up based on a key (like a materialized view in SQL)).
This [0] section in the readme of the underlying incremental dataflow framework may help get the concept across, but feel free to follow up if you're still not seeing the incrementality.
[0]: https://github.com/TimelyDataflow/differential-dataflow#an-e...
- Dbt and Materialize
- Materialized view questions
What are some alternatives?
react-query-firebase - React Query hooks for managing asynchronous operations with Firebase. Supports Authentication, Analytics, Firestore & Realtime Database.
ballista - Distributed compute platform implemented in Rust, and powered by Apache Arrow.
use-pagination-firestore - 🔥 React hook for non-cumulative pagination of Firebase Firestore collections
materialize - The data warehouse for operational workloads.
strapi-connector-firestore - Strapi database connector for Firestore database on Google Cloud Platform.
reflow - A language and runtime for distributed, incremental data processing in the cloud
rowy - Low-code backend platform. Manage database on spreadsheet-like UI and build cloud functions workflows in JS/TS, all in your browser.
differential-datalog - DDlog is a programming language for incremental computation. It is well suited for writing programs that continuously update their output in response to input changes. A DDlog programmer does not write incremental algorithms; instead they specify the desired input-output mapping in a declarative manner.
react-famous - React bridge to Famo.us
timely-dataflow - A modular implementation of timely dataflow in Rust
Redux Slim Async - :alien: A Redux middleware to ease the pain of tracking the status of an async action
clj-3df - Clojure(Script) client for Declarative Dataflow.