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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Keep your CRUD off the Internet

25 点作者 io大约 12 年前

8 条评论

obviouslygreen大约 12 年前
Aside from being an advertisement, this does make a reasonably decent point for some use cases... though I don't believe most of them are ones that are commonly solved with web-based CRUD.<p>However, letting people do these things offline on mobile devices introduces non-trivial problems of its own.<p>You've now turned your presumably-consistent, probably-IT-department-managed central database into, at best, a hub that's only eventually consistent. Someone's on vacation and made some updates on their phone? Sure, it looks like it was applied. Better hope they get back in cell range or on a network again for long enough to update -- and that they have a way to monitor it and ensure it was successful -- and at this point you're losing at least part of the convenience this was supposed to enable.<p>You've also now created the necessity for more robust conflict resolution. When you get two people editing the same data in a live web form, you can at least invalidate the second person's update if you're keeping last-updated timestamps. This approach falls on its face in an edit-offline-then-upload model because you now either have to automatically merge changes (yikes), re-create deleted records that were edited (and deal with dead references, yikes), or implement a prompt to get the user to resolve it themselves (unhappy user and yikes).<p>Of course, you also have to decide who should get how much and which of your data synced, make sure it's secure, and supply some mechanism so that a careless user can't drop his phone while not locked and allow someone remote access. Making sure the data is irretrievable without the phone being unlocked and the user signed in to the app is the least of your worries, but still something to worry about. Plus you have the potential for sensitive user data being distributed to places it shouldn't be, e.g. PCI compliance issues...<p>I'm sure there are other issues here, but this is not a replacement; with just these issues it's a totally different paradigm. That doesn't mean it's a bad idea, but it definitely will not drop in nicely and take all that awful CRUD out of our internets.
评论 #5595852 未加载
评论 #5595986 未加载
评论 #5595855 未加载
dustingetz大约 12 年前
For apps that read a lot more than they write, there exist ACID databases in which reads don't have to touch network, while retaining consistent writes. Datomic is one; for those who have never studied datomic, the database storage is immutable in the same way that Git commits are immutable, which enables a lot of git-like things in your database, like queries without network. That way your apps can be fast without giving up ACID.<p>I don't know if anything like Datomic exists on mobile; and OP is talking about mobile apps not webapps; so OP may be kind of correct, at least today.
评论 #5596014 未加载
sc8大约 12 年前
With everything going mobile, and mobile not being so well connected, i'm looking at writing to local mobile storage, and then later syncing that storage to the server, when a connection is available.<p>This is perfect timing for me.<p>Thx.
评论 #5595795 未加载
lawl大约 12 年前
I disagree. This surely depends on the type of crud application you're trying to build. We have a few in house business apps here, REST API and a JS frontend in the browser. Works fine, and since all our operations are atomic everything that doesn't come back with a 200 OK is fairly easy and generic to handle. The system also wouldn't be really usefull if the data weren't always up to date.<p>I get the point OP is trying to make but it really depends on what you are trying to build.
thatthatis大约 12 年前
It seems to me that sync is the last mile for a great write once deploy everywhere (Mobile + Web apps) framework.<p>What I really want is a meta framework that runs rails/django for backend + angular/ember for frontend + cordova/phonegap for mobile + responsive display with HTML/JS/CSS + something for syncing to allow offline mobile. Ideally this would be loosely coupled so you could choose your components (i.e. write a native mobile app if you want, or do the backend with Go, etc.)<p>The two pieces still missing are the sync component and the glue that keeps you from having to define the same thing multiple times. Unless there's something open source I'm unaware of.
davidwihl大约 12 年前
How is this going to sync just a slice of the database rather than everything in a given table? I would only want to publish one subset rather than all rows?
评论 #5595818 未加载
评论 #5595783 未加载
jordan_clark大约 12 年前
Like others have stated, I think it depends. Look at your target market. If the market is the USA, mobile connections are getting more reliable and really fast (LTE) and this isn't much of a problem.<p>OP should market this to devs focusing on countries where mobile networks stink.
评论 #5595995 未加载
miljan大约 12 年前
Nice approach; I like going through the SQLite API.
评论 #5595978 未加载