Promise support

[abramz]

Are you guys planning on supporting promises?

Currently, your callback function signatures do not lend themselves well to promisification as the callback is called with 2 arguments (result and response) on success. This requires developers to manually write a wrapper for all of the functions they want to promisify.

edit: I would be more than happy to contribute a PR, but want to know if this is in your road map and if you have opinions as to how it should be implemented.

[craxal]

Agreed. This would make the client API much nicer to code against.

[jamesdixon]

This would be great!

[anildukkipatty]

Yes. More than happy to help.

[agilbert201]

Agree. Example of wrapper I used to get around this for now https://gist.github.com/agilbert201/de1fe06def2b3a344c1a

[jamesdixon]

Not an expert on this by any means, but would promisification be possible using Bluebird's promisifyAll() with a custom promisifier? Seems like that's the purpose of the custom promisifier, but a little stuck on where to start.

[jamesdixon]

This hasn't been updated in a while, but am liking the interface: https://github.com/tracker1/node-azure-storage-simple

[sethreidnz]

@jamesdixon I have tried to use promisifyAll on the returned object from azureStorage.createBlobService() and it doesn't work. It gives me an error about not passing a callback. I thought that bluebird handled non-promise aware APIs but perhaps this module is doing something in its parameter validation that means it doesn't work? Would love to see this possible

[abramz]

@JustSayNO did you use a custom promisfier?

[sethreidnz]

I used Bluebird.js? I'm not sure what you mean but custom but I just did what the documentation here sugggests:

http://bluebirdjs.com/docs/api/promise.promisifyall.html

When I have moment I'll post code sample.

[abramz]

As @jamesdixon said, you have to use a custom promisfier when you use promisifyAll. Azure calls the callback with 3 arguments, error, result, and response IIRC. This is not the node convention, and so you have to tell bluebird how to handle this.

[dongseok0]

@JustSayNO I use like this. https://gist.github.com/dongseok0/9312eacc2db52e2f8846d39c08088465

[ricklove]

I look forward to this being ready.

Here is my best workaround for Typescript which maintains autocomplete and intellisense support for arguments (which promisify breaks).

Update: I found a serious bug because I forgot to wrap the call in a try catch.

import { StorageError, ServiceResponse } from 'azure-storage';
import { createBlobService, BlobService, createQueueService, QueueService } from 'azure-storage';

export function asyncIt<T>(call: (serviceCallback: (error: StorageError, result: T) => void) => void): Promise<T> {
    return new Promise<T>((resolve, reject) => {
        try {
            call((error, result) => {
                if (error) { reject(error); }
                resolve(result);
            });
        } catch (err) {
            reject(err);
        }
    });
}

async function usage() {
    // --- Blobs ---
    const blobService = createBlobService();

    // Create a blob
    let blob = await asyncIt<BlobService.BlobResult>(cb => blobService.createBlockBlobFromText('container', 'blob', 'text', cb));

    // --- Queues ---
    const queueService = createQueueService();

    // Write a Message (No Return)
    await asyncIt(cb => queueService.createMessage('queue', 'text', cb));

    // Read a Message
    let message = await asyncIt<QueueService.QueueMessageResult>(cb => queueService.getMessage('queue', 'text', cb));
}

The main problem is having to declare return Types as the type inference cannot determine types from a nested callback argument.

[hasonmsft]

@ricklove , to support promise, there will be a breaking change. It's already in our backlog and we'll try to fix it in an appropriate time. Will get you updated when it's ready.

[ricklove]

@hasonmsft Ok, thanks!

Btw, why not just make an optional wrapper using something like the above?

It wouldn't change the existing interface, it would just be in a different module. In fact, I'm sure it could be automated easily enough and use the existing documentation. I don't so how it would have any negative effects on any existing consumers.

[alippai]

Any news on this? Node.js supports async await now, so this would enable a really nice syntax to work with Azure storage.

[XiaoningLiu]

We are planning Node.js client library v2 this year which will fully support promise style.

[anoff]

Looking forward to that :)

[heyAyushh]

please please please

[Verikon]

Util.Promisify seems to work in my use case (Node >= 8)

import Azure from 'azure-storage';
import {promisify} from 'util';

let bls = Azure.createBlobService(account, key)
bls.getBlobToStream = promisify(bls.getBlobToStream).bind(bls);

[abramz]

You can use promisify all as well, then you don't need to bind. You also lose the SpeedSummary and response doing this.

…

On Wed, May 23, 2018, 6:43 AM Verikon ***@***.***> wrote: Util.Promisify seems to work in my use case. ` import {promifisy} from 'util'; let bls = Azure.createBlobService(account, key) bls.getBlobToStream = promisify(bls.getBlobToStream).bind(bls); ` — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD4v2UJMR0B321d7T_Y3c-lgzboiggZFks5t1WeTgaJpZM4HCer_> .

[DanaEpp]

So where are we on a new node library to support async/await/Promise ???

[Cellule]

promisify works great, but as mentioned you do lose SpeedSummary in some cases.
Also, because I want to keep using TypeScript and I want to keep intellisense when I'm using the API I had to write something like

  // Blob APIs
  getBlobMetadata(container: string, blob: string, options?: BlobService.BlobRequestOptions): Promise<BlobService.BlobResult> {
    return util.promisify(this.blobService.getBlobMetadata.bind(this.blobService))(container, blob, options);
  }
...
  // Queue APIs
  createQueueIfNotExists(queue: string): Promise<QueueService.QueueResult> {
    return util.promisify(this.queueService.createQueueIfNotExists.bind(this.queueService))(queue);
  }

which is super verbose and I just wish there was native support for promise from the module.
So far, every other azure module I've used have promise support

[seguler]

Hey folks! We are currently working on a new Storage SDK for JS with Promise support! Stay tuned!

[seguler]

Here is the PR for the new Storage SDK for JS: Azure/azure-storage-js#1

Looking forward to everyone's feedback!

[chriskuech]

Interesting that these docs manually add support for promises and describe the value of promises: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-nodejs

[XiaoningLiu]

@chriskuech This doc is for legacy callback style azure-storage-node SDK, users need to wrap a promise based on the callbacks.

Please try with the @azure/storage-blob V10 SDK, which has native promise support.

[shavidzet]

Any update there?

[craxal]

@shavidzet The developers said that v10 SDK and up have native Promise support, and they're not going to be adding it to older versions. I've been using v12, and it works great.

[murraybauer]

Yes, but still awaiting Azure Table support in v10+

[AshUK]

Yeah we need table support..

[johnkors]

@XiaoningLiu Could you comment on Azure Table Storage support?

[nikolabebic95]

Agree. Example of wrapper I used to get around this for now https://gist.github.com/agilbert201/de1fe06def2b3a344c1a

I borrowed your code and modified it a bit, to create a TypeScript version of the azure table reader: https://gist.github.com/nikolabebic95/8f872396d92994493dec157dcc9d825b

[XiaoningLiu]

Refer to https://www.npmjs.com/login?next=/package/@azure/data-tables for next generation table SDK : )