Allow for creating new clients by key

[dbmartin00]

For sure, if you are only working on treatments for a single client then you can create the client as follows:

var factory = splitio({
core: {
authorizationKey: 'browser key here',
key: 'user_id' // unique identifier for your user
}
});

var client = factory.client();

But if you want to get treatments for many different users, it is inefficient to construct an entirely new client this way. Instead, you can reuse the factory and supply a new client key with this kind of call:

client = factory.client(key);

Here, the key can be set to an entirely different user id, reusing much of the under-the-hood SDK workings and speeding things up.

If the could be updated with a new key then it could be reused. Creating a for each unique user can be resource intense otherwise.

[dbmartin00]

This is about updating the SplitProvider. Github is easing my markup.

[samuelcastro]

Hey @dbmartin00, is it safe to always return a factory.client(key, trafficType?)?

So key is a required prop and trafficType optional, I have two options:

1 - Always create client with a key: factory.client(key) or factory.client(key, trafficType)
2 - Add a new prop on SplitProvider let's say: isSharedClient: boolean and return client conditionally like: isSharedClient ? factory.client(key) : factory.client()

Thoughts?

Thanks.

[dbmartin00]

In my head, there's a sequence...

• Construct a client from the minimum necessary config:

var factory = splitio({
core: {
authorizationKey: 'browser key',
key: 'david' // unique identifier for your user
}
});

var client = factory.client();

In this example, the resulting client is for looking up treatments for david specifically. Let's say that there are more unique keys I want to look up. I could construct a new client the same way as shown above, or I could provide the key for the second client specifically:

client = factory.client('samuel')

Swapping keys this way is a big cost savings under the hood. The 'samuel' client is just as reusable as the 'david' client, it's just that you didn't have to pay as much cost to be ready.

Does this make sense?

[samuelcastro]

The thing is, since key is a required config prop, I think it'd make total sense to always return client by key: factory.client(key), don't you think?

Trying to understand why one would want to return a brand new client every time, since it'd consume more resource as far as I could understand.

[dbmartin00]

Simplicity is a good thing.

…

On Fri, Sep 6, 2019 at 2:33 PM Samuel Castro ***@***.***> wrote: The thing is, since key is required config prop, I think make total sense to always return client by key: factory.client(key), don't you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=ACLY5KBROJFSXXBZKX2EVZ3QILEDFA5CNFSM4IUNALP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6EDVMQ#issuecomment-529021618>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLY5KBRZNODROJSJNSODE3QILEDFANCNFSM4IUNALPQ> .

[samuelcastro]

@dbmartin00 I've fixed it by simply creating clients with the key as we discussed: factory.client(key), I'm assuming per our discussion that this is the best approach since it'll bring performance improvements.

I've released it as beta for now and you can install it through: npm install react-splitio@0.1.8-beta.1 or yarn add react-splitio@0.1.8-beta.1.

[CarsonF]

@samuelcastro I don't think the change made is correct. Things are shared only if the factory is saved. If using a different provider to change the key and trafficType a whole new factory will be created.

@dbmartin00 Are you needing multiple clients at once? Maybe we should support multiple clients regardless since splitio does. If so, maybe we need another way to specify this.

Maybe the SplitProvider could be used for shared settings and storing the factory. Then we have another component to store the client.

<SplitProvider config={{ core: authorizationKey: process.env.REACT_APP_SPLITIO_KEY }}>
  <SplitClient key="carson" trafficType="...">
    <Split feature="...">
  </SplitClient>
</SplitProvider>

Maybe we could make it so SplitClient isn't needed to use the default.

Something like this actually makes more sense for my use case too. I know the user (and thus key/traffic type) after SplitProvider has already been setup with the static authKey, etc. And thus I need to run all of it again just to change the key/trafficType.

[dbmartin00]

The complexity comes in when you want to evaluate flags for many unique keys on a single page or app. The idea of separating the provider from the client looks like a good way to model this. The toy example I have uses 100 different keys on one page, iterated with a nested map call. I don’t want to declare a split provider in every iteration of the loop, but so far this is necessary.

[CarsonF]

Cool, I'll work on a PR.

The toy example I have uses 100 different keys on one page, iterated with a nested map call. I don’t want to declare a split provider in every iteration of the loop, but so far this is necessary.

You have 100 different clients? That doesn't sound like a good thing...

[samuelcastro]

Ok perhaps I misunderstood it, based off what I heard from @dbmartin00 we just needed to create clients passing in the key and therefore the split.io SDK would shared it accordingly. But reading the SDK doc now I've noticed that we actually need to create the client first and then share it afterwards:

// now when you call factory.client(), the sdk will create a client 
// using the Account ID and traffic type name (if any) 
// you passed in during the factory creation.
var account_client = factory.client();
// to create another client for a User instead, just pass in a User ID 
// and an optional Traffic Type to the factory.client() method. 
// This is only valid after at least one client has been initialized.
var user_client = factory.client('CUSTOMER_USER_ID', 'ANOTHER_TRAFFIC_TYPE');

@CarsonF I will take some time to review your PR, but honestly I don't like the idea of creating another component to make it work, maybe we can find another way, I haven't thought in a way to solve it yet though.

[CarsonF]

I don't like the idea of creating another component to make it work, maybe we can find another way, I haven't thought in a way to solve it yet though.

I hear you. The thing is we are just "react-ify-ing" the splitio library. The splitio library allows you to use multiple clients, so so should we.

As you see in the docs, the default client needs to be created first and additional clients are optional. My PR is inline with this. The SplitProvider still creates and provides the default client. Optionally you can use SplitClient which provides a different client to its children.

[samuelcastro]

Yes absolutely, we need to provide a way to include this feature, but maybe we could fix it without creating another component. Let me give it a thought.

[CarsonF]

We could try to squash it into SplitProvider so it can be nested, but this seems more complicated than it's worth. Also SplitProvider and SplitClient have different inputs; the former requires the authorizationKey and accepts other config, the latter only accepts a key and trafficType.