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.)
Related
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.
I am currently in the process of implementing pagination, sort and search functionalities in the project files/plans/sheets views of BIM 360 Docs integration.
Since I couldn't find any best practices regarding to these features, I thought I would reach out so that I don't keep stuck reinventing the wheel.
Background:
Most of the implementation uses https://github.com/Autodesk-Forge/forge-api-dotnet-client/ SDK.
Based on what I saw it looks like there is no built-in results sorting in the Forge/BIM 360 APIs. BIM 360 Docs looks as if it sorted results on the client.
One has to cache all the results as structured data on the client in order to provide the sorting functionality. That also does not play well with any pagination approach.
Question:
Is there a way to sort results using the API, so that they come back in a predefined order, also while paginating?
According to our engineering team, the "sort" feature isn't currently supported by Forge Data Management API. Apologizing for the inconvenience caused.
I have logged a request FDM-1813[Support sorting in APIs of BIM360 integration] in our internal system to our engineering team to allocate time to evaluate the possibility. As it required some time to complete this task, please remember this request id for the future reference. You're welcome to track updates or provide additional information by quoting this request id via forge.help#autodesk.com.
However, a workaround is to fetch all data from the API, then sorting on the client side via Javascript.
Cheers,
I've been thinking about a project I'd like to start using the Google Drive API. My idea was to make a webpage (using Laravel) to let guests download files. I'd have 3 different types of users: the guests, that would be able to download files, the logged in users, that would be able to upload files, and the admins, which would be able to do all of that plus delete files (these files would be PDFs only).
Also, the server it would run on wouldn't have a lot of hard drive space for storing the files, it would just host the page and maybe keep some of the most important files. But the thing is, I have no experience whatsoever with this API. And I would hate to go through all of this trouble just to discover that it can't be done. I've tried reading the documentation but I still don't know if this is doable, and I can't find reliable tutorials (also, I don't know what is reliable, I've never worked with it).
So, for anyone who has already done something with the API, is this doable? Will the download speeds be too slow? Will users without accounts be able to download? Also, do you know any tutorials that are reliable and do it the right way? Or is the documentation the only thing I'll find/need?
Thanks in advance.
Yes,
All three cases can be handled with google drive sdk. You need to explore API in depth. Creation and downloads are easy and upload is tricky.
I recently used google drive api in a chrome extension that uploads images directly to drive here
You can ask questions regarding api usages here.
To start with, I would suggest going through one of the given Quickstarts in Google Drive REST API Overview.
Secondly, please note of the Requirements and Best Practices that a Drive API integration must adopt.
As mentioned:
Requirements
Following an "open with" action, applications must check that the user is authorized to read/write the document to which the passed document ID refers.
Best practices
In the "create new" flow, Google Drive provides your application with an authorization code. This code should be upgraded to an access token as soon as possible before applications take other actions.
Lastly, this SO post - Good tutorial on Google Drive SDK and OAuth might also help.
I received this email and due to my lack of experience in google drive, I am unsure of how to go about troubleshooting this.
Google
IMPORTANT: Steps to migrate from discontinued Documents List API
Hello administrators,
We recently posted a reminder that Documents List API will be discontinued on April 20, 2015. This change means that service calls for this API will no longer be supported, and any Google Apps features that are implemented using this API will no longer function.
Our records indicate that you may have an application that uses Documents List API, and we recommend that you migrate to Drive API, which has comparable functionality, as soon as possible.
Here's what you need to do:
Determine if you have an application that makes requests to these types of URLs:
(took out urls since this format did not allow me to send more than two)
Migrate the applications to Drive API.
If you have questions about migration, please contact Google Apps for Work Support.
Sincerely,
The Google Apps for Work Team
How do I determine, which, if any, docs are going to cease to function post 4/20? Is there a way to organize my current list of docs (I have many) to see how many I need to pay attention to? In terms of migrating, is there a migrating tool available online?
From what I have read, I feel like this doesn't even pertain to my current drive. My understanding is that this is for developers not casual users such as myself. Am I wrong in that assumption?
Thank you for all your help in this matter. If I am not explaining everything to the level you need, please let me know. I am just confused by the email and want to make sure I stay ahead of this.
Best,
Nathan
The key part of the email is Our records indicate that you may have an application that uses Documents List API
If you have such an app (you should know since by implication, you wrote it), then you have a lot of work to do over the next two weeks. If you don't, then relax. Your documents are not affected by this announcement, only the app that Google thinks you once wrote.
It's possible it's referring to an app you have installed, in which case there is nothing you can do other than hope the developer has a new version.
In my case Google Apps Sync for Microsoft Outlook and Google Drive Windows seem to be the 2 applications that are requesting access to these depecrated scopes ... Come on Google, spread the word internally !
I basically want to write an app that uses the Drive API. developers.google.com has tutorials on how to do that. But problem is that their example asks me to first create an app engine instance, which I don't want to, as I've heard pretty bad reviews about it. So, I just wanted to know whether there is/are any alternative/s available, and what challenges I would possibly have to face when using the service/s.
You can write a Drive app on any platform that can make an HTTPS request, so pretty much, any platform. When you choose one, if you have any problems, get back to us.
Also, you should probably try out App Engine before making a decision based on "reviews you read".
AppEngine has a few convenience classes around Credential storage and User Id. Aside from that a standard servlet app and a GAE app are pretty much the same.