How can you share containerIds in a real world application?

[thaoula]

Hi All,

I am new to the Fluid Framework so please excuse me if these questions have been documented somewhere (I have looked but cannot find anything specific).

In all of the examples I have seen, we do the following -

1. We get a containerId when we call container.attach
2. We then put containerId in the hash part of the browser url.
3. We copy this URL and paste it into another browser and then we can join the same container.

In our application I have many objects that I would users to collaborate. An example is our Project entity which contains tasks that users need to complete.

Since it is stored in the database it already has unique id. When creating a container I want to use the an application specific ID not one provided by the Azure Relay Service. The reason for this is that when users collaborate on this object I want to ensure all users are connected to the same container.

Without a known containerId each call to contain.attach would result in a new container being created and no collaboration would happening.

If I create a container on the service side each time I create a project I would have thousands of containers that are bound a specific Azure Fluid Relay and it would also mean I would have to run a utility to generate containers for previously created projects.

So my questions:

1. Is there any way to use application specific key rather using the random key obtained from attach?

2. If we cannot do 1, how do we prevent multiple containers from being created .. ie. multiple users open the same project at the same time .. say during a teams meeting. Each would go to the project screen, the would not have a containerId, they would attach and multiple containers would be created?

Regards,
Tarek

[tslocke]

I'm also new to Fluid, so don't take this as experienced advice, but I'm interested in the answer to this question so I thought I'd share my thoughts.

If your server environment is Node, maybe you can import the Fluid library and create the container on the server.

If not, you could create the container in the client, and have a POST endpoint like /projects/:id/setContainer, passing the new container ID. If the server already has a containerID (because another client did the same thing at the same time), it could return something like {rejected: true, containerID: '...'}. The client would then call .dispose() on the container it just created, and then client.getContainer to get the real container.

In both cases, you'd want to use a database transaction to ensure that checking for an existing container ID, or saving the new one, was an atomic operation.

[thaoula]

Hi @tslocke ,

Thanks for the reply.

Yeah I thought about doing something like that and will probably have to revert to doing something like that. I was really hoping for the Fluid Relay to allow application's to use their own ids to represent a container.

For example, we use OneSignal for push notifications to mobile devices. Rather than having to know the unique ids of every IOS and Android device a user has. We send a message to OneSignal using the userId in our application and it sends out the message. It knows the userId because when we register with the service we can pass this id.

In the meantime, I will try your approach since it is probably the most workable at this stage.

Regards,
Tarek