I’m thinking about building an offline-enabled web application.
The architecture I’m considering is as follows:
Web server (remote) <--> Web server/cache (local) <--> Browser/Prism
The advantages I envision for this model are:
- Deployment is web-based, with all the advantages of this approach
- Offline-enabled
- UI (html/js) synchronization is a non-issue
- Data synchronization can be mostly automated
- as long as I stay within a RESTful paradigm
- I can break this as required but manual synchronization would largely remain surgical
- The local web server is started as a service; I can run arbitrary code, including behind-the-scene data synchronization
- I have complete control of the data (location, no size limit, no possibility of user deleting unknowingly)
- Prism with an extension could allow to keep the javascript closed source
Any thoughts on this architecture? Why should I / shouldn’t I use it? I'm particularly looking for success/horror stories.
The long version
Notes:
- Users are not very computer-literate.
For instance, even superficially
explaining how Gears works is totally
out of the question.
- I WILL be held liable if data is loss, even if it’s really the users fault (short of him deleting random directories on his machine)
- I can require users to install something on their machine. It doesn’t have to be 100% web-based and/or run in a sandbox
The common solutions to this problem don’t feel adequate somehow. Here is a short analysis of each.
Gears/HTML5:
- no control over data, can be deleted
by users without any warning
- no
control over location of data (not
uniform across browsers and
platforms)
- users need to open application in browser for synchronization to happen; no automatic, behind-the-scene synchronization
- different browsers are treated differently, no uniform view of data on a single machine
- limited disk space available
- synchronization is completely manual, sql-based storage makes this a pain (would be less complicated if sql tables were completely replicated but it’s not so in my case). This is a very complex problem.
- my code would be almost completely open sourced (html/js)
Adobe AIR:
- some of the above
- no server-side includes (!)
- can run in the background, but not windowless
- manual synchronization
- web caching seems complicated
- feels like a kludge somehow, I’ve had trouble installing on some machines
My requirements are:
- Web-based (must). For a number of
reasons, sharing data between users
for instance.
- Offline (must). The application must be fully usable offline (w/ some rare exceptions).
- Quick development (must). I’m a single developer going against players with far more business resources.
- Closed source (nice to have). Yes, I understand the open source model. However, at this point I don’t want competitors to copy me too easily. Again, they have more resources so they could take my hard work and make it better in less time than I could myself. Obviously, they can still copy me developing their own code -- that is fine.
Horror stories from a CRM product:
- If your application is heavily used, storing a complete copy of its data on a user's machine is unfeasible.
- If your application features data that can be updated by many users, replication is not simple. If three users with local changes synch, who wins?
- In reality, this isn't really what users want. They want real-time access to the most current data from anywhere. We had better luck offering a mobile interface to a single source of truth.
Menu
148
