I am a heavy user of Brave and I would love for you to expand on what you mean.
For those curious, here is the open-code repo of all Chromium changes Brave applies. I have not read every commit myself, so any flagging would be appreciated: https://github.com/brave/brave-core
I worked on LiveGraph for a long time at Figma. We went through our own evolution:
1. first we would use the WAL records to invalidate queries that could be affected (with optimizations for fast matching) and requery the data
2. then we used the info from the WAL record to update the query in-memory without asking the DB for the new result, it worked for majority of the queries that can be reliably modeled outside of the DB
3. I believe after I left the team reverted to the re-query approach, as managing a system that replicates the DB behavior was not something they were excited to maintain, and as the DB layer got scaled out, extra DB queries were less of a downside
Thoroughly enjoyed the article since I have heard about Neon but never understood what it offers on the technical level over other PG-compatible projects.
The article mentions that a consequence of separating storage from compute is that compute nodes cache hot pages in memory and load cold pages from object storage (like S3?) when needed. Does anyone know what are the consequences of this decision. In case of a query that touches multiple rarely used pages, would that incur high latency and ingress? How does that penalty compare to a vanilla postgres running on AWS and storing pages on EBS?
Oh yeah, a pure function that accepts previous state, and returns the new state is the pattern I use a lot.
The issue is that it is hard to do on complex graph structures in an algorithm where incremental changes happen to the graph O(n) times - it ends up creating complex code and complex execution that might be slow to pass the time limit on Codeforces, let's say.
In the OCaml world maybe this is the place where you say "screw it, this abstracted function does some stateful temporary business, but it looks pure from the outside" but in Haskell it's a lot harder to pull off without going deep into monads (and I forget how those work every time).
Slightly off-topic but what's a good forum to seek help on FP practices outside of the courses like this online?
Every winter break I get back into trying to learn more FP (in Haskell) and in the past several years I have been practicing algo problems (codeforces, advent of code, leetcode).
I always get stuck on more advanced graph algorithms where you traverse a and modify a graph, not a tree structure - it gets particularly tricky to work on circular data structures (I learned about "tying the knot" but it's incredibly challenging for me) and usually the runtime perf is sub-par both asymptotically and empirically.
I only read the article once, but to me it seemed like this was an explicit requirement: produce a vector artifact that renders the same on all platforms without dependencies (basically a PDF?) and without invoking a browser in the build process.
Sort of like folks would praise Go's ability to compile a static binary without dylib dependencies besides libc.
Does it support exporting to SVGs without requiring the used fonts installed on the viewer's system? That seems to be the issue the author is trying to address.
For others looking for more details on how Figma's sync engines differ and why 2 sync engines emerged, I had a long thread about it here:
https://x.com/imslavko/status/1890482196697186309