Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keep your CRUD off the Internet

ericsink.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Keep your CRUD off the Internet

#11

Post by camus »

obviouslygreen wrote: post #4

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. However, letting people do these things offline on mobile devices introduces non-trivial problems of its own. You've now turned your presumably-consistent, probably-IT-department-managed central database into, at best, a hub that's…

So why do you suggest ? dropping any offline/online sync feature because the implications (for crud apps)? i guess you could have a system checking what resource has been updated since last connection and explicitly alerting the user the commit has failed due to an update that happened between the offline edit and the connection, or keep track of all the versions ( which is hard to manage if resources have relationships and depend on other resources ) Anyway that's a subject i'm really into so any resource on the matter is welcomed , i'm really looking for the holy grail of data syncing.

Re: Keep your CRUD off the Internet

#12

Post by dustingetz »

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.

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.

Re: Keep your CRUD off the Internet

#13

Post by obviouslygreen »

camus wrote: post #11
obviouslygreen wrote: post #4

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. However, letting people do these things offline on mobile devices introduces non-trivial problems of its own. You've now turned your presumably-consistent, probably-IT-department-managed central database into, at best, a hub that's…

So why do you suggest ? dropping any offline/online sync feature because the implications (for crud apps)? i guess you could have a system checking what resource has been updated since last connection and explicitly alerting the user the commit has failed due to an update that happened between the offline edit and the connection, or keep track of all the versions ( which is hard to manage if resources have relationsh…

I think the viable scope of such a replacement is there but probably very limited. In my opinion it depends on the type, format, frequency of editing, sensitivity, and many other properties of the data you're working with.

Perhaps the solution isn't sending CRUD mobile, but rather replacing it in some circumstances with more limited, potentially check-in/check-out, simplified and abstracted workflows that make sense in specific situations. Trying to replace it like this in a general sense presents more problems than it solves.

Re: Keep your CRUD off the Internet

#14

Post by jordan_clark »

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.

OP should market this to devs focusing on countries where mobile networks stink.

Re: Keep your CRUD off the Internet

#15

Post by EvanAnderson »

miljan wrote: post #3

Nice approach; I like going through the SQLite API.

cough WebSQL cough

So many apps, HTML5 or native, could benefit from an offline sync story. That wheel doesn't need to be re-invented over and over again.

This reminds me a lot of WebSQL, which I've always been sad was killed.

Re: Keep your CRUD off the Internet

#16

Post by chacham15 »

obviouslygreen wrote: post #4

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. However, letting people do these things offline on mobile devices introduces non-trivial problems of its own. You've now turned your presumably-consistent, probably-IT-department-managed central database into, at best, a hub that's…

Their general idea is very similar to svn vs. git. That use case has proven to be very effective. Im sure that you can find use cases that this is more difficult to apply (where row conflicts cannot be automatically merged) but there are also use cases where this idea works like a gem.

Re: Keep your CRUD off the Internet

#17

Post by GFischer »

jordan_clark wrote: post #14

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. OP should market this to devs focusing on countries where mobile networks stink.

And where would that be? I thought it was the U.S. which was backwards !! :) (and I live in Uruguay, South America).

That said, I'd love it if more of my apps worked offline with sync.

Re: Keep your CRUD off the Internet

#18

Post by ericsink »

dustingetz wrote: post #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 g…

I need to look at Datomic.

Zumero could also be described as having similar characteristics as Git. It's like a DVCS, except for stuff that looks like rows and columns instead of stuff that looks like directories and files.

I'm sure that any decentralized database violates ACID in some way, but Zumero is pretty darn ACIDic. All the local CRUD operations are ACID. And the sync to the server is ACID, or highly corrosive at minimum. But yes, the two operations are separate.

Re: Keep your CRUD off the Internet

#19

Post by troebr »

camus wrote: post #8
sc8 wrote: post #2

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. This is perfect timing for me. Thx.

I'm looking for some articles about how to do syncing 101 by the way , i heard it's kind of hard. If anyone has good links about the subject ( on HTML5 offline/online sync db server ) , it would be great.

I made a kind of todo/list pet project with html5 local storage earlier. All the front end was based on that storage, then it was only a matter of syncing. To do that I kept a queue in local storage, that I only emptied after a successful sync. Then you need to define conflict rules based on what you synced, and that is case-by-case.

For instance for me, deleting a task meant anything else regarding that task later was disregarded, it's deleted. Updates to tasks were treated by timestamp. For creating tasks, I had to have a temporary id that I updated after syncing, to a permanent id.

tldr; queue, precedence rules and timestamps.

Re: Keep your CRUD off the Internet

#20

Post by thatthatis »

It seems to me that sync is the last mile for a great write once deploy everywhere (Mobile + Web apps) framework.

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.)

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.

Post reply on HN