According to Edit files on 3rd-party storage systems article it is possible to edit Google Docs, Sheets, and Slides (Google files) stored on 3rd-party storage systems, such as Box.
Are there public API to provide a possibility to introduce an integration with extra 3rd party storage system (like it is done for example in Box for G Suite native integration, i.e. a file is automatically saved in Box instead of Drive)? Does it require business or enterprise G Suite account?
Thanks.
You could build your own integration with the Google Drive API to transfer content into and out of Google Drive, assuming you're comfortable with exporting and importing that content as traditional Office docs rather than Google's format.
If you'd like to use it with an arbitrary 3rd party storage system, one way is to build your own app that integrates with both Google and that storage system to allow you to transfer content between them.
Neither of these approaches require your Google account to specifically be a Business or Enterprise account. With both approaches, the data is actually saved within Google Drive but then synced to the other storage platform as well behind the scenes. If that is acceptable, then these solutions might meet your requirements.
Tools like Kloudless let you connect to several different cloud storage SaaS apps and protocols with a single implementation. (Disclosure: I'm the CTO). Check out Kloudless' unified Storage API docs and the Kloudless File Explorer to prompt users to pick files to sync.
Related
I'm a voice-over artist. I am creating a web app in which the client can make orders & upload video/sound/image/text files, I download these files to edit them then i upload the edited files & allow the client to download them.
Which is better for this purpose?
Taking in consideration
I want to allow the client to preview the edited file (video) in the
browser
Security
File privacy [I mean no one can reach the file except the client who made the order]
Performance
Price
There is no definitive answer to your question.
It confuses many customers that two, such seemingly functionally similar services, are available.
That said -- generally -- for applications where a service (your web app) is the intermediary, Google Cloud Storage (GCS) is the more appropriate solution.
GCS is a lower-level service than Drive and so you'll have a little more work to do to integrate it but it provides richer functionality too particularly with regards authorization and being able to provide more specificity about who can do what. Lastly, GCS enables so-called "Signed URLs" that would e.g. permit you to provide your customers with a secure and time-bound URL where they may upload content.
One possibly determining feature is that a Google Drive account is oriented around an individual (generally human) user (e.g. you) and your Google Drive does not permit other users to upload files; only you can create files in your Drive account although you can then share these with others.
I hope this helps you decide which service is best-suited to your needs. GCS is a very widely used service and is well-documented. You should be able to find plenty of guidance to help you develop a solution using it.
I've just learned that Google Realtime API is now deprecated. It is suggested to migrate to Firestore instead. However, Firestore's model is not built around Google Drive so it will not be possible to manage and share real-time documents via Google Drive.
Is there any alternative migration path that would keep files stored in Google Drive?
For example, real time documents may have a simple API endpoint that would allow to get and save them as pure JSON. This would mean that we can keep using Google Drive to store our data and only use Firestore to handle real-time editing sessions (if this is needed).
I don't think you'll find any off-the-shelf solutions natively supporting Drive as a backing source, but if you can export your data model as JSON, Convergence can probably handle it. (In full transparency, I am a founder)
It is almost certainly the quickest way to get back to feature parity with the Realtime API, and probably beyond, as we have first-class support for UX features you probably want as well, beyond just the data synchronization.
Yes, you can export your Realtime data via a separate REST API detailed here:
Exporting Realtime Data This ability should remain available after the realtime API is turned down on January 15th, 2019, though Google has not stated for how long, AFAIK
(Firestore doesn't seem to offer any Operational-Transform-like conflict resolution, so is not a viable alternative for applications that currently have good reasons to use the realtime API, though that is Google's only suggestion so far.)
I have developed an app that integrates with Google Drive. It makes use of the sharing features. Is there a good way for me to beta test this app while still allowing the same experience as an app in the store? I would like to iron out any bugs and performance issues before releasing to the general public.
Thanks!
The app doesn't need to published in the store in order for it to be installed, simple include the https://www.googleapis.com/auth/drive.install scope when prompting the user for authorization (more information here). Once you are ready to publish, there also ways to test your listing before you make it available to everyone.
If I write an entire web app in GAS and then it gets popular and it starts receiving a thousand requests per second. Is there any way to either pay Google to handle it, or host my GAS app on non-Google infrastructure, in the same way that here does for Google App Engine?
Your GAS script scales up automatically. The only thing that you should be worried about is your code where, if you have locks, thousands of users waiting for a lock will cause delays to the user. Other than that, scaling up shouldn't be a problem. After all, there are possibly millions of scripts being run by different users.
I've never seen Google suggest Apps Script is the tool for that kind of scale. Go to App Engine, do not pass Go, etc.
There is no third-party implementation of the Google Apps Script services. It is, however, a JavaScript implementation on Java (think Rhino) which you can run yourself - or you could run on App Engine and use the Java GData APIs to replace the Apps Script services.
if the App is running under the user account (execute the app as the user accessing the web app) it will consume each user's quotas and use their own account resources (docs, sheets, etc). This would allow for 'unlimited' scalability.
This is just my own view, am I right or totally wrong?
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.