[keycloak-dev] Promise wrapper for javascript adapter

Raymond DeCampo ray at decampo.org
Tue Sep 5 08:58:26 EDT 2017


First, if I were to integrate Promise support into the Keycloak, I would be
leaving the current javascript adapter as is.  This would be an extension
in a separate javascript file so that only developers who are interested
would get the Promise interface.  Existing code using the current adapter
would be unaffected.  The new code would be a wrapper around the existing
code so that maintenance would only be required if the javascript adapter
API changes.

In terms of browser support, caniuse.com[1] indicates that Promise has
broad support; only IE 11 and Opera Mini fail to support Promise.  However
polyfills are available to provide support.

As far as the advantages, the main ones as I see it are: 1) using the
standard promise API makes it easier for developers new to the library; 2)
using the standard promise API makes the library more interoperable with
other libraries; and 3) ES6 Promise objects are chainable making sequences
of asynchronous calls cleaner to code.

I think the MDN page on Using Promises[2] probably makes a better argument
for than I'll be able to here.  But the main thrust is that chaining makes
it so it is not necessary to have so many nested functions.

For example, suppose I am writing a javascript client for a REST API
protected by Keycloak.  Since the built-in fetch() method returns a Promise
with ES6 Promises I can write:

        // assume authz.updateToken() returns an ES6 Promise
        authz.updateToken(5).then((token) => {
            return fetch(this.ENDPOINT, {
                redirect: 'error',
                headers: { "Authorization": "Bearer " + token }
            });
        }).then((response) => {
            showResult(response.text());
        }).catch((error) => {
            displayError(error);
        });
    }

Since everything is standard, any JS developer would understand the code.
Since both libraries use Promise, I can chain the promises without nesting
functions.  And since both libraries use Promise, I can use catch() at the
end for unified error handling whether the error comes from the Keycloak
adapter or from the call to fetch().


[1] http://caniuse.com/#search=Promise
[2]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises


On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I don't know much about ES6 native Promises. Can you give me some details
> about it? What browser support it? What are the benefits of using that
> instead of our howegrown approach? Etc.
>
> On 4 September 2017 at 20:36, Raymond DeCampo <ray at decampo.org> wrote:
>
>> Hello all,
>>
>> I create a wrapper around the javascript adapter which uses ES6 native
>> Promises.  (https://github.com/RayDeCampo/keycloak-promise).
>>
>> If you are interested, I can re-package it for inclusion in Keycloak and
>> create a pull request on GitHub.  If you have a different process for
>> contributions, let me know.
>>
>> If you are not interested, no hard feelings.
>>
>> Thanks,
>> Ray
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>


More information about the keycloak-dev mailing list