@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.

@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.

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.

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