TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Web Applications from the Future: A Database in the Browser

184 点作者 frant1c将近 4 年前

19 条评论

dgreensp将近 4 年前
Having been a dev on EtherPad, Google Wave, Coda, and other real-time collaborative apps with OT, undo, and so on...<p>I think it&#x27;s correct that, ideally, there would be a framework that handles real-time collaboration, undo&#x2F;redo, and offline support for you, and then you build your app with these problems already solved. I will probably create such a framework eventually. I don&#x27;t see it as a database engineering problem, it&#x27;s more like a framework or application architecture, which every app like Google Docs or Figma has its own version of. Writing such a framework is not too much harder than writing such an app, it just requires a little more abstraction and some documentation.<p>If you&#x27;ve never written an undo manager, sync engine, etc., and you aren&#x27;t writing a complex app, it&#x27;s hard to arrive at the right design by thinking about pure data sync. Also, storing and querying data are solved problems; it&#x27;s more a question of coming up with a generic data model for an application and defining its semantics.
评论 #27436814 未加载
评论 #27440132 未加载
评论 #27442482 未加载
评论 #27435608 未加载
评论 #27434533 未加载
评论 #27441147 未加载
评论 #27436587 未加载
评论 #27436409 未加载
评论 #27436847 未加载
rektide将近 4 年前
I don&#x27;t mind the technical discussion at all, it&#x27;s a fun write-up, but if you &quot;look at the the ecosystem of web applications and measure by difficulty&quot; and find the most difficult possible app you can, and using that to shape your vision of how to build web apps, lionize what a web app is, I think one is very very liable to end up with a completely non-web monster that ignores many of the strongest strengths of application &amp; site design that are possible.<p>Google Docs is themselves moving to canvas based rendering, which might as well be turning the screen into a giant VNC session into their codebases[1]. Web, dead, pushing pixels in people&#x27;s faces, in. All the extensions that extend &amp; enhance Google Docs are about to die, being replaced with a very small, much narrower API provided explicitly by google.<p>I see statements like,<p>&gt; This gets me excited about whats to come, because what&#x27;s at the edge of difficulty today tends to become the new normal tomorrow.<p>And think, please, let us not be path dependent on a web-recreation of classic desktop apps. The web is more interesting, it has online content, liveliness &amp; connectivity to it that far surpasses the other platform&#x27;s norms. Let us think of how we might advance the web for good web things. There&#x27;s worth &amp; value to examining hard problems, but I am worried that this attitude has us set out to build faster horses.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27129858" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27129858</a>
评论 #27437391 未加载
vaughan将近 4 年前
Great post. Captured the problem nicely. I went on a similar journey recently.<p>There is a moment when you step back and realize that all the data-wrangling code we write in apps is essentially what an SQL query planner does. And our frontend is just one big materialized view that we need to update.<p>I often think that if we had a database that runs in the browser, and we could subscribe to queries, and missing local data would be fetched on-demand, frontend development would be a lot easier. Its of course much more complicated than that.<p>I think the reality though is that backend scaling requirements always end up dwarfing frontend productivity concerns. And there is also a huge amount of glue between backend data sources, preventing the creation of a clean database on the backend to sync with, meaning we are creating API gateways and GraphQL federation layers, and all we can hope for is a good client-side caching layer.<p>If you look deeper though you will find many projects doing all these kinds of things already. Mobile developers are very familiar with offline techniques and SQLite on the client, and it doesn&#x27;t feel like anything special to them. For the web&#x2F;desktop, maybe no one has packaged it in the right way yet, or maybe we are still digesting GraphQL, SSR, and serverless, and then there will be another shift with offline-first, reactive SQL in the frontend.<p>It&#x27;s funny though that if you think long enough about these concerns, you always seem to end up wanting some Datalog thing.
ampdepolymerase将近 4 年前
Not a single mention of CRDTs or operational transforms in the article. If all you need is a client side database to replicate Figma and Google Docs then they would have long shut down.
评论 #27436511 未加载
评论 #27431292 未加载
code-is-code将近 4 年前
You should have a look at RxDB which does exactly what you have described. Also notice that neither firebase nor supabase is really offline-first.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;pubkey&#x2F;rxdb" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pubkey&#x2F;rxdb</a>
评论 #27436151 未加载
eyelovewe将近 4 年前
We had Meteor with “mini mongo” and you locally subscribed to streams and it was all a quite bloated PÓS IIRC. At some point someone will make a virtual browser that runs in the browser, or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete. Just replace the browser and use ports 80 and 443 and be done with it, instead of pretending that cpu cycles and RAM are free. The browser is not the app platform of the future, it’s the current bandaid solution is all. I also don’t agree that this article is well written. It exclusively addresses the world according to front end dev, mulch as graphql does. I’m sorry that coding elaborate stuff requires you to keep track of your elaborate stuff. Set your global var equal to the parsed xhr.result and redraw your GUI and get over it, IMO
评论 #27427635 未加载
评论 #27429506 未加载
评论 #27442455 未加载
评论 #27428301 未加载
Cthulhu_将近 4 年前
this comment turned into a bit of a personal rant, apologies.<p>I really liked this post, because it touches on so many things that I have to build as well at the moment. I&#x27;m building a configuration management interface; the front-end is basically authentication and heaps of forms, the back-end transforms it into XML and uses some shell scripts to rsync them to servers and SNMP to trigger a deployment. But the users have worries about overwriting each other&#x27;s work, they ask for undo &#x2F; revert support, and there&#x27;s things like audit logging, user and permissions management, etc involved.<p>At the moment I&#x27;m slowly building all of that with a React&#x2F;TS front end and a Go backend using a REST API, just trying to be as tidy and complete as possible. But it&#x27;s a lot of work, and I&#x27;m afraid that once I get to things like versioning, locking, undo &#x2F; revert, auditing and permissions, my fairly straightforward codebase will just explode in complexity, with each endpoint having loads of documentation and code to represent the different concerns. Client- and server-side validation is another concern, importing existing data, migrating user data from a staging to production environment, etc.<p>It&#x27;s a lot. It&#x27;s a project that should be done by a full team of developers, maybe even multiple but ATM I&#x27;m doing it on my own.<p>I&#x27;ll never finish it. I&#x27;m currently trying to plough through and make sure everything is set up, but I&#x27;m hoping we&#x27;ll get a big financial injection and I&#x27;d be able to hire a bunch of consultants (that I&#x27;m familiar with as being decent if expensive developers).<p>I don&#x27;t know how the previous guy managed to get as far as he did on the older version, other than being a mediocre but productive and persistent developer for all that time, seeing the whole thing grow over time instead of trying to reach feature parity with a product nine years in the making.
评论 #27436988 未加载
whoisnnamdi将近 4 年前
This is an incredibly well-written article and helps track and rationalize some of the trends I&#x27;ve been seeing as well around backends as a service that enable developers to easily spin up modern web applications<p>Thanks so much for writing it!
评论 #27436888 未加载
ralusek将近 4 年前
To me it always come down to permissions. I&#x27;ve tried firebase, I&#x27;ve tried graphql. I just can&#x27;t use them for anything other than admin endpoints or things with very simple permissions. I&#x27;m glad the author mentioned permissions, but I would need to see some seriously compelling evidence that I could trust a declarative, resource-based permissions system to accomplish what I need.
评论 #27437014 未加载
评论 #27436649 未加载
abss将近 4 年前
You should also look to OpenDSU (opendsu.com) that covers in a unique ways these aspects. Basicaly it goes to build on the vision in wich applications are running inside digital wallets and you control your data (client side encryption) while beeing able to collaborate with others and get security in a decentraliassd way using various types of anchoring in ledgers (not necesarly distributed or your typical blockchains but of course this could be the case too)
tlarkworthy将近 4 年前
Just use Firebase (firestore) ...<p>It&#x27;s got: offline first, latency compensation, pubsub, partial sync, authorization rules and serverside timestamps, and global transactions, and 5 9s availability backed by spanner for umpteen languages. <a href="https:&#x2F;&#x2F;tomlarkworthy.endpointservices.net&#x2F;blogs&#x2F;firestores-technical-advantages.html" rel="nofollow">https:&#x2F;&#x2F;tomlarkworthy.endpointservices.net&#x2F;blogs&#x2F;firestores-...</a>
评论 #27444857 未加载
评论 #27446417 未加载
j-pb将近 4 年前
There is a very handy RDF DL subset that has all of the desired properties described in the article.<p>Funnily enough we are targeting the browser AND FPGAs, and I think the latter is the much more interesting use case for a distributed reactive CRDT-like database.<p>Datalog is actually trivial to incrementally materialize in open world semantics. Which is why datomic (while a great foundation in theory) turns out to be non ideal. TxnIDs and retractions are essentially nonmononic negation in disguise, and CALM (consistency as logical monotonicity) a.k.a. distributedness, doesn&#x27;t go well with that.<p>Seeing that we&#x27;re not the only ones dreaming of this gives me hope though, that we might get out of the tar pit someday.
zubairq将近 4 年前
We already have this in Visual Javascript. When you build an application and export it as HTML it has a full SQL database that runs just in the browser: <a href="https:&#x2F;&#x2F;github.com&#x2F;yazz&#x2F;visualjavascript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;yazz&#x2F;visualjavascript</a>
twobitshifter将近 4 年前
[Automatic Undo&#x2F;Redo Using SQLite](<a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;undoredo.html" rel="nofollow">https:&#x2F;&#x2F;www.sqlite.org&#x2F;undoredo.html</a>)<p>No sure on the scalability of SQLite but here’s a simple way to get database undo&#x2F;redo.
enos_feedler将近 4 年前
A lot of the principles here echo the same design principles that MeteorJS was built on. Why didn&#x27;t that work and why now? Is there something about _today_ that makes the web application space different?
评论 #27445204 未加载
farnulfo将近 4 年前
API rate limit exceeded for user ID 984574.
评论 #27440463 未加载
评论 #27441228 未加载
thewakalix将近 4 年前
About storing history rather than current-state: I think Urbit works similarly.
nickthemagicman将近 4 年前
Getting API rate limit exceeded.<p>What is this hosted on?
psvj将近 4 年前
this site appears to have exceeded its API rate limit. I wonder if that is a problem what will be solved by &#x27;web applications of the future&#x27;. but i guess ill never know now
评论 #27442668 未加载