This is actually a topic that has interested me for a while. A couple months ago I wrote a program which was intended to be run locally on users' machines and i

This is actually a topic that has interested me for a while. A couple months ago I wrote a program which was intended to be run locally on users' machines and interacted with via an embedded JSON API and web app. I realized I could (theoretically) point a domain, e.g. app.myapp.com, to 127.0.0.1 and then instruct the user to 1. install program 2. browse to app.myapp.com to use it That led me to start thinking about applying this to a "hybrid" application which is hosted but which stores user data locally using a "sidecar" app. (I was thinking about larger, more complex web applications where I might not want to store 100% of user data in e.g. local storage or cookies) You might have the following DNS records: 1. app.myapp.com -> <hosted app> 2. api.myapp.com -> <hosted api> 3. user-data.myapp.com -> 127.0.0.1 Create a basic application which runs an HTTP API for retrieving/updating locally-stored user data. When a user signs up, let them know that their data is stored locally and they'll need to install an application. When your application needs to interact with constantly updating data (e.g. weather, finance, etc.), make requests to api.myapp.com for that data. When it needs to interact with user data, it makes requests to user-data.myapp.com which resolves to the user's local machine. Obviously there's a number of things which aren't great (or that I haven't fully thought out): - If the local API runs on port 80, it would require that the user isn't running anything else on that port. Also, the application would need privileges to bind to 80. If it isn't running on port 80 (preferable), how do we pick a port which avoids collisions with ports used by other applications and how do we enable the user to communicate the port their local API is running on to the web app. - Securing user data from malicious apps - you'd want to make sure that only your application (and the user) can access the user's data. The same-origin policy would "prevent" any web application from talking to the local API, so you'd need to enable CORS for whichever domain is hosting your web app. CORS would help with this situation, but I don't think it would 100% solve it - there's still vulnerabilities like DNS rebinding that you'd have to consider. - Securing user data from data loss - if e.g. a user's disk died or their laptop was stolen and they didn't maintain their own backups, they'd lose their data - Sync between devices - e.g. if a user signs up for a service which stores their user data locally on their computer via something like this, how would it work if they opened the app on their iPhone? - "Moving fast without breaking things" - if you make changes to the hosted and local apps which breaks compatibility with the current versions and requires the user to update, how do we force the user to upgrade their local app without it becoming a nuisance? This could be solved with an app which maintains backwards compatibility and slowly deprecates APIs, allowing users months between requiring updates to the local application. You could also just write an incredibly generic local API which doesn't require updates often. Some of these are problems which existed before but which users' didn't need to think about because developers managed them - e.g. securing user data from data loss. Others are introduced specifically because of this architecture - e.g. syncing user data, increasing complexity, etc. For the average user who may not care _that_ much about the privacy of their data, some of these trade-offs and increased complexity might not make sense. If anyone has any further thoughts about this approach or why it's a terrible idea, I'd love to chat more! Email in my profile.