Aqueduct Container Services #930

skylerjokiel · 2020-01-15T01:48:24Z

This is a first run at adding Container Services concept into the Aqueduct.

The goal of Container Services is to service developers who want to write components but don't need those components to have DDSs. This has become a common pattern on Bohemia. Tony wrote the v1 of this in the runtime and I have ported it up to the framework. I believe that the runtime should own the container request handler pattern and the Container Services is just a framework extension of that.

This change doesn't have any components using it (coming soon) but it does add some V1 tests to the aqueduct as well as simple docs in the README that describe Container Services.

There are two types of Container Services provided in this original PR.

The SingletonContainerService is probably the most common and will provide a service at a given id with a 1 to 1 mapping with the container. All developers within a container who ask for the object will get the same one back.

The InstanceContainerService will new up a new object every time a developer asks for one. This could be potentially useful for services that return viewable ui objects where you don't want the views to always be the same. But since I haven't explored maybe this is just throw away. The goal was to provide an extensible interface with two simple implementations.

…nto aqueduct-container-services

tylerbutler · 2020-01-15T16:23:35Z

Do you guys really like the word "service" in this context? I think of something very different from what is described here when I hear "service."

tylerbutler · 2020-01-15T16:27:06Z

packages/framework/aqueduct/README.md

+
+You can provide custom Request Handlers to the Container. These request handlers are injected after system handlers but before the component get. Request Handlers allow you to intercept request made to the container and return custom responses.
+
+An example of this is if I want to have a random color generator. I could create a RequestHandler that when someone makes a request to the Container for `{url:"color"}` will intercept and return a custom `IResponse` of `{ status:200, type:"text/plain", value:"blue"}`.


"Consider a scenario where you want to create a random color generator. I could create a..." #Resolved

tylerbutler · 2020-01-15T16:28:35Z

packages/framework/aqueduct/src/components/sharedComponent.ts

@@ -17,6 +17,8 @@ import { IComponentContext, IComponentRuntime } from "@microsoft/fluid-runtime-d

 import { ComponentHandle } from "@microsoft/fluid-component-runtime";

+import { serviceRoutePathRoot } from "../helpers";
+
 /**
 * This is as bare-bones base class that does basic setup and enables for factory on an initialize call.


nit: I know this isn't from your change but there's a typo here. Should be "This is a"

definitely from one of my past prs. lol

anthony-murphy · 2020-01-15T17:08:48Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+// TODO: should this just be "s"?
+export const serviceRoutePathRoot = "_services";
+
+export interface IContainerService {


I'm not sure these interfaces are necessary, and i think they could create confusion. I'd prefer if container services were just IComponents, and i think these interface could lead people to think container services should be runtime components, which is explicitly an anti-pattern.

I also worry that this is limiting. For instance, undo-redo isn't and shouldn't be coupled to aquaduct, but it and other such libraries should be able to participate in the container services.

I spent some time today playing with different implementations. I landed on this model but with a factory pattern where the factory interface lives in framework-definitions. The reason we want a factory is because I really want to inject the IHostRuntime object into the service. Having access to this object dramatically extends the quality of these services and it's not possible to do that if you have to create the ContainerService object before you create the ContainerRuntime.

I do agree that a ContainerService should just be an IComponent so I removed the requirement of being an IComponentRouter.

We talked about moving the concept of services to the framework level and if we do that we can't make statements that services will function correctly across frameworks. If we want to enforce that we need to move the logic to the runtime level. If we want loose enforcement we can add it to framework-definitions which I've done in the second iteration. If we want no enforcement (which v1 has and I agree is wrong) we should leave it in the Aqueduct.

I feel this is a lot of complexity for something I'm not sure we need. For the IHostRuntime it's only hard to get if using our simple runtime factory, as it's all hidden, for any complex container they'll likely need to handle that code, and then it's not hard to get the IHostRutime.

The problem still exists even if you're a container writer. The problem is that you need to provide your service to the container on creation. So if you want your service to have a reference to the container (IHostRuntime) you have a circular dependency and need a factory so that you create the service the first time someone asks for it. At this point we have the container.

packages/framework/aqueduct/src/helpers/simpleContainerRuntimeFactory.ts

anthony-murphy · 2020-01-15T17:17:44Z

Do you guys really like the word "service" in this context? I think of something very different from what is described here when I hear "service."

https://en.wikipedia.org/wiki/Service-oriented_programming

tylerbutler · 2020-01-15T17:31:07Z

@anthony-murphy Thank you! I learned something new today. Achievement unlocked. This sentence helped it click for me: "An in-memory service in SOP can be transparently externalized as a web service operation."

skylerjokiel · 2020-01-15T23:55:44Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+// TODO: should this just be "s"?
+export const serviceRoutePathRoot = "_services";
+
+export interface IContainerService {


I spent some time today playing with different implementations. I landed on this model but with a factory pattern where the factory interface lives in framework-definitions. The reason we want a factory is because I really want to inject the IHostRuntime object into the service. Having access to this object dramatically extends the quality of these services and it's not possible to do that if you have to create the ContainerService object before you create the ContainerRuntime.

I do agree that a ContainerService should just be an IComponent so I removed the requirement of being an IComponentRouter.

We talked about moving the concept of services to the framework level and if we do that we can't make statements that services will function correctly across frameworks. If we want to enforce that we need to move the logic to the runtime level. If we want loose enforcement we can add it to framework-definitions which I've done in the second iteration. If we want no enforcement (which v1 has and I agree is wrong) we should leave it in the Aqueduct.

packages/framework/aqueduct/src/helpers/simpleContainerRuntimeFactory.ts

skylerjokiel · 2020-01-15T23:59:02Z

packages/framework/aqueduct/README.md

+
+The concept of Container Services is simple. We define a specific request route that when queried against returns IComponent objects. The Container Developer can then pass in ContainerServices that other components can query for. These IComponent objects are different from the Components we talked about before in the sense that they do not directly have a `ComponentRuntime` backing them so they can not have Distributed Data Structures. Because they don't contain Distributed State they only exist in memory and will be re-created either with every Container instantiation or on every call (depending on the type).
+
+Container Services can 


Finish thought. #Resolved

skylerjokiel · 2020-01-16T00:03:41Z

packages/framework/aqueduct/src/components/sharedComponent.ts

@@ -17,6 +17,8 @@ import { IComponentContext, IComponentRuntime } from "@microsoft/fluid-runtime-d

 import { ComponentHandle } from "@microsoft/fluid-component-runtime";

+import { serviceRoutePathRoot } from "../helpers";
+
 /**
 * This is as bare-bones base class that does basic setup and enables for factory on an initialize call.


definitely from one of my past prs. lol

…nto aqueduct-container-services

kurtb · 2020-01-16T00:29:00Z

Do you guys really like the word "service" in this context? I think of something very different from what is described here when I hear "service."

In the systems sense service works - since they are behaving like OS level services - vs. meaning a web service. I suppose you could say daemon too if you wanted a split.

kurtb · 2020-01-16T00:38:49Z

The other tool we have for this is the scope parameter that gets past on load. It's intended to provide host level services. But you could create an aggregate component that merges host level 'services' with those provided by the runtime.

I wonder how re-usability will work here. As Scriptor moves to become a reusable component I expect they'll package these up into things the base Scriptor component makes - as opposed to things you register at the runtime level. That way you just drop in your scriptor component and load it up and you're good to go - vs. needing to register a bunch of global services for it to work.

I'd expect component developers may also need to inherit some of these services from elsewhere. In the case of Teams/OWA they probably would want you to play with their clipboard/undo if possible - vs. do your own. So you may need to check the host scope regardless and only create your own local versions in the absence of one. The scope passed to the render methods also can give UX specific functionality. The old attach method was designed for this - you'd exchange components as part of attaching and could them QI for stuff you have. But that got deprecated in favor of scenario specific scopes.

Component creation could also be aware that the given component doesn't summarize or deal with ops - to be slightly more efficient - in which case code-only components could move to the platform layer as well.

The nice part with something like the above is you can deal with handles. In general with handles that can be serialized in a map, etc... we should avoid people having hard coded routes. Should be able to do everything with object references/serialized handles at this point.

skylerjokiel · 2020-01-16T01:28:42Z

@kurtb you raise a ton go good concerns and I don't see this as the final form of services but a first step. The question of reconciling application scope (services) with container services is something tony and I have talked about a lot and there definitely needs to be a solution there. Currently this doesn't exist but will need to be developed going forward.

All the Scriptor comments are well defined. How to construct Containers dynamically is a great question that I don't have a good answer for. We definitely need a way for Services to be re-useable across Containers and I think we have that here (in V2) where they can be packaged and consume independently of the Aqueduct. We do need components to be enhanced by services but we don't have a good idea of what it means for a Component to be dependent on a service. The Scriptor team has been doing a lot of work and thinking a lot about how they can be less dependent on external services.

As I said at the beginning. A lot of good questions and problems to solve and I'm not trying to answer them here. I'm just trying to get a V1 concept in that people can start building off of and we can iterate on.

…nto aqueduct-container-services

anthony-murphy · 2020-01-16T01:40:25Z

@kurt one thing I like about not having these managed by the runtime is there is no attach message. The container code just instantiates what it wants. this solves a bunch of problem around what is created when and by who.

I'm also not sure we would want handles to these things, as different hosts may provide different features, so depending where a container is hosted the services could differ on where they come from.

I've played around with hosting services at routes that are keyof IComponent, it basically works out that the container have a service registry Map<keyof IComponent, IComponent> . This is cool because you can then check the host scope on all requests to see if the host scope implements the interface, and if does, return that instead of the registered service.

…nto aqueduct-container-services

skylerjokiel · 2020-01-16T22:52:01Z

I synced with @anthony-murphy , I've made changes to remove common interfaces and to make the services pattern simpler.

Now we will accept a registry of services with an id/creation function. We will then use the factory pattern behind the scenes to ensure that only one is created per container. We still allow developers to access the IHostRuntime object so they can leverage what's available there.

These services will only be created once someone asks for them.

anthony-murphy · 2020-01-17T19:21:13Z

packages/framework/aqueduct/README.md

+
+The Aqueduct framework provides two Container Service Factories as well as an optional base class for building Container Services.
+
+#### SingletonContainerServiceFactory


update doc please

anthony-murphy · 2020-01-17T19:22:50Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+ * @param serviceRegistry - Collection of Container Services
+ */
+export const generateContainerServicesRequestHandler =
+    (serviceRegistry: [string, (runtime: IHostRuntime) => Promise<IComponent>][]): RuntimeRequestHandler => {


rather than an array you the serviceRegistery could be Iterable, which is a bit more flexible, as it supports maps too

anthony-murphy · 2020-01-17T19:24:29Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+
+    private service: IComponent | undefined;
+
+    public get IContainerServiceFactory() { return this; }


I don't think this is needed anymore

anthony-murphy · 2020-01-17T19:25:04Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+    public get id() { return this.serviceId; }
+
+    public constructor(
+        private readonly serviceId: string,


you could just make this public, and get ride of the id property

anthony-murphy · 2020-01-17T19:26:24Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+export const generateContainerServicesRequestHandler =
+    (serviceRegistry: [string, (runtime: IHostRuntime) => Promise<IComponent>][]): RuntimeRequestHandler => {
+
+        const factories: SingletonContainerServiceFactory[] = [];


maybe make this a map for easier lookup later

anthony-murphy · 2020-01-17T19:28:05Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+
+            const service = await serviceP;
+            const router = service.IComponentRouter;
+            if (router) {


if there is more path, and the service isn't a router i think we should fail

anthony-murphy · 2020-01-17T19:30:28Z

packages/framework/aqueduct/src/helpers/sharedComponentFactory.ts

@@ -24,7 +24,7 @@ export class SharedComponentFactory implements IComponentFactory, Partial<IProvi

    constructor(
        private readonly ctor: new (runtime: IComponentRuntime, context: IComponentContext) => SharedComponent,
-        sharedObjects: readonly ISharedObjectFactory[],
+        sharedObjects: readonly ISharedObjectFactory[] = [],


i don't think we should default this on shared component, as you should always be specifying some dds

I think that's a fair point now that we have services :)

anthony-murphy · 2020-01-17T19:32:36Z

packages/framework/aqueduct/src/helpers/containerServices.ts

+import { RequestParser, RuntimeRequestHandler } from "@microsoft/fluid-container-runtime";
+
+// TODO: should this just be "s"?
+export const serviceRoutePathRoot = "_services";


related #977

anthony-murphy

A few comments, but looks good.

…nto aqueduct-container-services

skylerjokiel added 10 commits January 13, 2020 16:51

first run of container services

a04da7d

comment

c5d2531

seperate container services

f0ea523

lint fixes

6a3af60

tests

50085d2

Merge branch 'master' of http://github.com/microsoft/fluidframework i…

b891187

…nto aqueduct-container-services

fix up some build errors

6357ac2

add some tests for the container services

6906fd4

add some tests

c40d5a8

update readme

6a82fe4

skylerjokiel requested review from tylerbutler, anthony-murphy, ChumpChief and curtisman January 15, 2020 01:48

tylerbutler reviewed Jan 15, 2020

View reviewed changes

anthony-murphy reviewed Jan 15, 2020

View reviewed changes

packages/framework/aqueduct/src/helpers/simpleContainerRuntimeFactory.ts Show resolved Hide resolved

skylerjokiel added 3 commits January 15, 2020 12:04

Upgrade to have different IContainerService pattern

25658e9

use factory interfaces instead

fa0b271

readme and nit

6430ee2

skylerjokiel commented Jan 16, 2020

View reviewed changes

Merge branch 'master' of http://github.com/microsoft/fluidframework i…

f41cfb8

…nto aqueduct-container-services

skylerjokiel requested a review from anthony-murphy January 16, 2020 01:16

Merge branch 'master' of http://github.com/microsoft/fluidframework i…

4b54efa

…nto aqueduct-container-services

skylerjokiel added 6 commits January 15, 2020 17:45

add copyright header

b0cde24

Merge branch 'master' of http://github.com/microsoft/fluidframework i…

dfeb579

…nto aqueduct-container-services

fix some lint errors

38b29da

changes to make things simple

552655c

add back factory concept

d33782e

Merge branch 'master' of http://github.com/microsoft/fluidframework i…

94e7ed9

…nto aqueduct-container-services

anthony-murphy reviewed Jan 17, 2020

View reviewed changes

anthony-murphy approved these changes Jan 17, 2020

View reviewed changes

skylerjokiel added 6 commits January 17, 2020 14:21

changes to make things better

10be0a2

use a map instead of an array.

d77a417

update README

a9ae3f7

Merge branch 'master' of http://github.com/microsoft/fluidframework i…

fbf74c3

…nto aqueduct-container-services

package-lock update

00bb07b

small fix

0bab1d4

skylerjokiel merged commit 5b24031 into microsoft:master Jan 17, 2020

skylerjokiel deleted the aqueduct-container-services branch January 17, 2020 23:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Aqueduct Container Services #930

Aqueduct Container Services #930

skylerjokiel commented Jan 15, 2020

tylerbutler commented Jan 15, 2020

tylerbutler Jan 15, 2020 •

edited by skylerjokiel

Loading

tylerbutler Jan 15, 2020 •

edited

Loading

skylerjokiel Jan 16, 2020

anthony-murphy Jan 15, 2020 •

edited

Loading

anthony-murphy Jan 15, 2020 •

edited

Loading

skylerjokiel Jan 15, 2020

anthony-murphy Jan 16, 2020

skylerjokiel Jan 16, 2020

anthony-murphy commented Jan 15, 2020

tylerbutler commented Jan 15, 2020

skylerjokiel Jan 15, 2020

skylerjokiel Jan 15, 2020 •

edited

Loading

skylerjokiel Jan 16, 2020

kurtb commented Jan 16, 2020

kurtb commented Jan 16, 2020

skylerjokiel commented Jan 16, 2020

anthony-murphy commented Jan 16, 2020 •

edited

Loading

skylerjokiel commented Jan 16, 2020

anthony-murphy Jan 17, 2020

anthony-murphy Jan 17, 2020

anthony-murphy Jan 17, 2020

anthony-murphy Jan 17, 2020

anthony-murphy Jan 17, 2020

anthony-murphy Jan 17, 2020

skylerjokiel Jan 17, 2020

anthony-murphy Jan 17, 2020

skylerjokiel Jan 17, 2020

anthony-murphy Jan 17, 2020

anthony-murphy left a comment


		You can provide custom Request Handlers to the Container. These request handlers are injected after system handlers but before the component get. Request Handlers allow you to intercept request made to the container and return custom responses.

		An example of this is if I want to have a random color generator. I could create a RequestHandler that when someone makes a request to the Container for `{url:"color"}` will intercept and return a custom `IResponse` of `{ status:200, type:"text/plain", value:"blue"}`.


		The concept of Container Services is simple. We define a specific request route that when queried against returns IComponent objects. The Container Developer can then pass in ContainerServices that other components can query for. These IComponent objects are different from the Components we talked about before in the sense that they do not directly have a `ComponentRuntime` backing them so they can not have Distributed Data Structures. Because they don't contain Distributed State they only exist in memory and will be re-created either with every Container instantiation or on every call (depending on the type).

		Container Services can


		The Aqueduct framework provides two Container Service Factories as well as an optional base class for building Container Services.

		#### SingletonContainerServiceFactory


		private service: IComponent \| undefined;

		public get IContainerServiceFactory() { return this; }

Aqueduct Container Services #930

Aqueduct Container Services #930

Conversation

skylerjokiel commented Jan 15, 2020

tylerbutler commented Jan 15, 2020

tylerbutler Jan 15, 2020 • edited by skylerjokiel Loading

Choose a reason for hiding this comment

tylerbutler Jan 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anthony-murphy Jan 15, 2020 • edited Loading

Choose a reason for hiding this comment

anthony-murphy Jan 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anthony-murphy commented Jan 15, 2020

tylerbutler commented Jan 15, 2020

Choose a reason for hiding this comment

skylerjokiel Jan 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kurtb commented Jan 16, 2020

kurtb commented Jan 16, 2020

skylerjokiel commented Jan 16, 2020

anthony-murphy commented Jan 16, 2020 • edited Loading

skylerjokiel commented Jan 16, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anthony-murphy left a comment

Choose a reason for hiding this comment

tylerbutler Jan 15, 2020 •

edited by skylerjokiel

Loading

tylerbutler Jan 15, 2020 •

edited

Loading

anthony-murphy Jan 15, 2020 •

edited

Loading

anthony-murphy Jan 15, 2020 •

edited

Loading

skylerjokiel Jan 15, 2020 •

edited

Loading

anthony-murphy commented Jan 16, 2020 •

edited

Loading