Cloudrail seems perfect to simplify interaction of a web page with e.g. google drive or other cloud service.
And this may be due to my lack of understanding and lack of knowledge of web development and Node.js, but can cloudrail be used serverless?
Or in other words can cloudrail be used on a stand-alone html page on a local computer (i.e. served by the filesystem instead of a server) and be made to access google drive or even work with an off-line mode while on a stand-alone html page (which may later sync with google drive)?
The reason being I would like to design a simple mobile app that accesses the cloud (fine so far) that is mirrored as a simple portable web page that can sit anywhere (desktop/laptop/mobile/USB stick) and is not served by any server but simply loaded from the local filesystem.
If not cloudrail, what other technology might I need to achieve this?
I don't think you can use it as a standalone website the way you describe it. You might be able to realize your use case though by e.g. using CloudRail's Nodejs SDK with Electron. This allows you to create an application very similar to a website with Javascript while still giving your users just one file that runs pretty much everywhere.
Related
I want to host some html files on Google Cloud and wondered, if this is possible to do, without adding a custom domain...
With for example Cloudflare or AWS, that's possible...
GCS objects can be loaded just fine from a web browser, with or without a domain. They follow either of these naming schemes:
https://storage.googleapis.com/YOUR_BUCKET_NAME/YOUR_OBJECT_NAME
https://YOUR_BUCKET_NAME.storage.googleapis.com/YOUR_OBJECT_NAME
If you simply need to serve resources via a web browser, this is quite sufficient.
If you need a bucket to represent an entire website, it'd be a good idea to use a custom domain. This enables a handful of nice, website-like features, such as defining default pages when none is specified as well as providing a customization 404 page.
You have three options (well, only two of them are really viable, but the last one can be useful in certain situations).
In order of ease to use and viability:
1) Google App Engine:
The default Google App Engine app is served out of *.appspot.com site, so if you create a project call "cutekittens", your site address will be cutekittens.appspot.com.
Furthermore, you can choose to do something simple like a static webpage, or you can host an entire webapp on Google App Engine. It's easy to use and very powerful. Google App Engine supports its own storage (Datastore), bigdata (Big Query), and MySQL (Cloud SQL) solutions and all of that can be served out of the default appspot.com site which acts the the front end.
2) Static Website on Google Cloud Storage. Google Cloud Storage is less powerful but should suffice if you just need a static website served. It uses "storage.googleapis.com/[BUCKET_NAME]/[OBJECT_NAME]", in which your object is probably an index.html.
3) Use a Google Compute Engine VM on static IP. This option is probably the MOST powerful, as you can do anything you want on your own VM. However this is also the less friendly usage since you will need the actual IP address to access the site and its resources.
Looking for high-level guidance as I'm not sure where I'd even start w/ this.
I'm making a web app where most (if not all) of my users will have installed a Chrome extension I've written.
What I'd like to do is include large libraries in the Chrome Extension, and have the web app load the libs from the extension when the user visits a site.
e.g., both the extension & web app use React (same version).
When user visits www.mywebapp.com, the extension would inject the React library into the page and skip downloading the script.
Is this possible and/or advisable?
That's probably not a good idea, because you don't directly control updates of your extension. And the two have to be more or less in sync.
Suppose you need to update your site. Then you want to update the extension as well. That's at mercy of Google, and takes time. It's best if such updates are fully controlled by your web app server.
There are much better mechanisms to speed up (subsequent) load time by using client-side caches such as ApplicationCache. Here are a few resources to start:
A Beginner's Guide to Using the Application Cache # HTML5Rocks
Your first offline web-app # Google Developers
Application Cache is a Douchebag (for some gotchas)
I'm teaching myself web development, and am working on a small and free web-app on the Chrome web store written in HTML and JavaScript. I'm trying to keep the app entirely client-side since I don't really want to pay a monthly fee for a web hosting service at this time. The app relies on localStorage for saving bits of text. I urge the user to back it up with copy/paste, but this is sort of a crude workaround.
Does anyone know how I might provide an interface for file management that involves only the user's hard drive or some sort of free file transfer service? Could an embedded Java applet do this? I basically want the functionality of the File API, apparently not yet implemented in Chrome (http://www.html5rocks.com/tutorials/offline/whats-offline/).
Nevermind--File API is implemented in Chrome. See http://www.html5rocks.com/tutorials/file/filesystem/ for a tutorial.
With many browsers adding proper local storage support (and with this whole HTML5 buzz), there is a lot of talk about offline web apps competing with desktop software. But, as a matter of fact - one quick "clear private data" on your browser (which a lot of people do) - clears all the local storage data.
I'm now thinking that local storage in browsers can at best be used to cache data temporarily before being sync-ed with the web server, but truly offline web applications can't rely on HTML5's local storage permanently due to the problem I outlined above.
Is there a scope for offline web applications that actually depend on data extensively?
My take on this is that the offline capability of online web apps can compete with desktop software, but not pure offline web-apps.
Why? Well, the major drawback of online web apps was what happens when you lose your network connection when doing any work. Seeing as this can be resolved now, the competition is truly on. Imagine editing a document online, then move around without internet, come back online and then sync the changes and continue to work as if nothing happened. That is truly awesome.
For this to work, the browser should allow to store data in a location that you can pick which would mean access to OS layer, which will probably not happen anytime soon...
I've started looking into HTML web database storage for some Chrome extension I'm working on, and it made me wonder - Who should be cleaning abandoned web databases? As opposed to desktop apps, there's no uninstaller for a web site. And as opposed to regular cookies, web databases can be much larger than just 4KB.
I can imagine some browsers or addons might give advanced users a way to clean up locally stored data, but I can't imagine my parents doing that. What will prevent web sites from clogging their hard drive once this feature is commonly used? Is there any way honest and responsible web sites can have their local data removed once they are not used anymore?
On the two websites and 4 apps I use html5 local storage in, I offer an option somewhere (off the About page, or in account settings, or a link at the bottom of the page) which gives you the ability to remove the local database and key-value pairs, as well as the option to opt-out of the site using it.
It'll be persistent, just like cookies. The difference with cookies is that you can store much more data and no expire date can be given.
Firefox has an option to clean those information automatically (Offline storage)