OneDrive as Cache platform
In Apps script library with plugins for multiple backend cache platforms I covered a way to get more into cache and property services, and the bmCrusher library came with built in plugins for Drive, CacheService and PropertyService. Google Cloud Storage platform cache plugin for Apps Script crusher showed how to extend this concept to other back end platforms, using Google Cloud Storage as the service. In this article I’ll show you how to write a plugin to use Microsoft One Drive as the backend
Benefits of using Microsoft OneDrive
Seems pretty crazy, right ? What’s the point when we have Cloud Storage, Property Service, Cache service and even Google Drive. Well, there’s this emerging goodie. Microsoft’s answer to Apps Script – maybe the next installment in the evolution of VBA, Office Script . I’ve written about JavaScript for Office in various posts on this site, and of course plenty about VBA (even a book about it), but Office Script is quite different. I’ll be writing about that quite a bit in coming posts. But to get back to the point – having a universal cache platform to share real time data easily between the Apps Script and Office script world sounds like it would be interesting. So that’s what this is leading to. We can also use much of the same code to read and write content directly to OneDrive for other stuff. But first, how to create the plugin on the App Script side.
How to use
Just as in the other examples, it starts with a store being passed to the crusher library to be initialized. The OneDrive version is going to have to use the OneDrive API, so we’ll need to write that from scratch and also handle authentication – but it’s pretty straightforward as you’ll see. Once the plug is written we can use it in the exactly the same way as the Google platform plugins – like this
You’ll notice I’m using goa for auhentication and authorization to OneDrive – see How fast can you get OAuth2 set up in Apps Script for more details. There’s a small amount of setup for that, so let’s get that out of the way. There are 3 steps
- Create an app your Microsoft DeveloperApp in their portal, and get some credentials. It’s here https://apps.dev.microsoft.com/
- Write them to your property store
- Deploy a web app so you can authorize it via the MS Oauth2 process, and set your callback url in the Microsoft developer profile.
- Delete all that and forget about it forever. It’ll take care of refreshing tokens etc.
OAUTH2
One off function to set up goa. You only need to run this once, then you can delete it.
Make and deploy this webapp, just to get Microsoft Oauth to talk to you
It’ll bring up this dialog
Take a copy of the redirect URI now, enter it into your Microsoft developer console as the authorized callback, then click start. It’ll go through the microsft dialog, and when it’s done (it won’t return anything), you can undeploy it and delete the doGet function. You’ll never need it again.
The plugin
Now we can get started on the plugin – it’s essentially the same as the Google Drive one, except this time we’re going to an external API.
And that’s all there is to coding up the plugin. From now on the exact same methods introduced in Apps script library with plugins for multiple backend cache platforms will now operate on OneDrive instead of the other platforms. Here’s a refresher
Writing
All writing is done with a put method.
put takes 3 arguments
- key – a string with some key to store this data against
- data – It automatically detects converts to and from objects, so there’s no need to stringify anything.
- expiry – optionally provide a number of seconds after which the data should expire.
Reading
get takes 1 argument
- key – the string you put the data against, and will restore the data to it’s original state
Removing
Expiry
The expiry mechanism works exactly the same as the other platforms. If an item is expired, whether or not it still exists in storage, it will behave as if it doesn’t exist. Accessing an item that has expired will delete it.
Here’s what some store entries look like on One Drive
Fingerprint optimization
Since it’s possible that an item will spread across multiple physical records, we want a way of avoiding rewriting (or decompressing) them if nothing has changed. Crusher keeps a fingerprint of the contents of the compressed item. When you write something and it detects that the data you want to write has the same fingerprint as what’s already stored, it doesn’t bother to rewrite the item.
However if you’ve specified an expiry time, then it will be rewritten so as to update its expiry. There’s a catch though. If your chosen store supports its own automatic expiration (as in the CacheService), then the new expiration wont be applied. Sometimes this behavior is what you want, but it does mean a subtle difference between different stores.
You can disable this behavior altogether when you initialize the crusher.
Formats
Crusher writes all data as zipped base64 encoded compressed, so the mime type will be text, and will need to be read by bmCrusher to make sense of it. However, there is probably a use case for the data to be kept in its original format so it can be used as a general One Drive storage client. I may add this at a later version if there’s a demand.
Links
bmCrusher
library id: 1nbx8f-kt1rw53qbwn4SO2nKaw9hLYl5OI3xeBgkBC7bpEdWKIPBDkVG0
Github: https://github.com/brucemcpherson/bmCrusher
Scrviz: https://scrviz.web.app/?repo=brucemcpherson/bmCrusher
cGoa
library id: 1v_l4xN3ICa0lAW315NQEzAHPSoNiFdWHsMEwj2qA5t9cgZ5VWci2Qxv2