Non-singleton authn

[cornerman]

I am using authn-js in an application and was wondering, whether we also want to support a non-singleton usage, like:

let authn = new Authn(hostname, storage)

or

let api = new AuthnApi(hostname)

We could still provide a global instance via the existing import so nothing changes for the end-user.

Another part of this: how do we go about authenticating against two different authn servers. Currently, that would not be possible due authn and api being a singleton.

Would you be open to a PR for this?

[cainlevy]

@cornerman That does sound like the right solution for two different AuthN servers. 👍

Meanwhile, I'm curious if you're willing to describe when having two different AuthN servers is useful? That's a new scenario for me.

[cornerman]

@cainlevy Fair question. Currently it is more theoretical, because it is not built yet :) But I was thinking about one ui for multiple independent backends that might share the implementation detail of using authn-server. Seemed like a simple solution to me.

So honestly, for now I can practically work with a singleton. But I have to admit, from a coding perspective, I prefer having a fully initialized authn instance instead of a singleton where I need to rely on someone having called setHost.

To be transparent: I am also trying to built a client sdk for usage in scala: https://github.com/cornerman/keratin-authn-scala. For the frontend, I am wrapping authn-js. So having this option also shapes the api. But of course that should not influence design decisions of this library.

[cainlevy]

I prefer having a fully initialized authn instance instead of a singleton where I need to rely on someone having called setHost

That makes sense.

The reason why I originally settled on the current singleton design was because I was interested in minimizing the client library's size. I remember trying ES6 classes and noticing a lot of extra weight in the bundled version.

I haven't reviewed the bundle targets for a while and it's possible something has changed there. However it may be simpler to forego ES6 classes and rely on older prototype patterns.

[cornerman]

I am happy to try something out and make a PR, where we can check the bundle size.