Update Hosts & Loaders + Fix Image issue (#3242)

Author: SamBroner

docs/content/docs/concepts/architecture/index.md docs/content/docs/concepts/architecture.md

@@ -20,8 +20,7 @@ Objects can have state, which is managed by Distributed Data Structures (DDSes).
 DDSes are used to distribute state to clients. Instead of centralizing merge logic in the
 server, the server passes changes (aka operations or ops) to clients and the clients perform the merge.
 
-![A diagram of the Fluid Framework architecture](./images/architecture.png)
-
+![A diagram of the Fluid Framework architecture](/docs/concepts/images/architecture.png)
 
 ## Design decisions
 
@@ -61,8 +60,8 @@ client, gives the op a sequential order number, and sends the ordered op back to
 structures use these ops to reconstruct state on each client. The Fluid service doesn't parse any of these ops; in fact,
 the service knows nothing about the contents of any Fluid container.
 
-![A diagram depicting operations being sent from a Fluid client to a Fluid service](./images/op-send.png)
-![A diagram depicting operations being broadcast to Fluid clients](./images/op-broadcast.png)
+![A diagram depicting operations being sent from a Fluid client to a Fluid service](/docs/concepts/images/op-send.png)
+![A diagram depicting operations being broadcast to Fluid clients](/docs/concepts/images/op-broadcast.png)
 
 From the client perspective, this op flow is accessed through a **DeltaConnection** object.
 
@@ -78,7 +77,7 @@ Fluid container code. In this way, the Fluid loader 'mimics the web.' The Fluid
 resolver,** connects to the Fluid service using the **Fluid service driver**, and loads the correct app code using the
 **code loader.**
 
-![A diagram of the Fluid loading sequence](./images/load-flow.png)
+![A diagram of the Fluid loading sequence](/docs/concepts/images/load-flow.png)
 
 **Container lookup & resolver** identifies, by a URL, which service a container is bound to and where in that service it
 is located. The Fluid service driver consumes this information.
@@ -100,4 +99,4 @@ used to replicate data across connected clients, but can also include additional
 incapsulated in our lowest level objects, **distributed data structures (DDS)**. App logic operating over this data is
 stored in **Fluid objects**.
 
-![A diagram of the Fluid loading sequence](./images/fluid-objects.png)
+![A diagram of the Fluid loading sequence](/docs/concepts/images/fluid-objects.png)

docs/content/docs/concepts/hosts.md

@@ -1,6 +1,114 @@
 ---
-title: Hosts and the Loader
+title: Hosts and the loader
 menuPosition: 4
 ---
 
-## NOT YET WRITTEN
+The **Fluid loader** is one of the key parts of the Fluid Framework. Developers use the Fluid loader within their
+applications to load Fluid containers and to initiate communication with the Fluid service.
+
+A **Fluid host** is any application that uses the Fluid loader to load a Fluid container.
+
+The Fluid loader uses a plugin model.
+
+
+## Who needs a Fluid loader?
+
+If your app or website will load a Fluid container, then you are creating a Fluid host and you will need to use the
+Fluid loader!
+
+If you are building a Fluid container and you will not build a standalone application with Fluid, you may still be
+interested in learning about the Fluid loader. The Fluid loader includes capabilities, such as host scopes, that are used
+by containers.
+
+You may also want to host your Fluid container on a standalone website.
+
+
+## Summary
+
+The Fluid loader loads Fluid containers by connecting to the Fluid service and fetching Fluid container code. From a
+system architecture perspective, the Fluid loader sits in between the Fluid service and a Fluid container.
+
+![A diagram of the Fluid Framework system architecture](/docs/concepts/images/architecture.png)
+
+The Fluid loader is intended to be extremely generic. To maintain generic-ness, the loader uses a plugin model. With the
+right plugins (drivers, handlers, resolvers), the Fluid loader will work for any wire protocol and any service
+implementation.
+
+The loader mimicks existing web protocols. Similar to how the browser requests state and app logic (a website) from a
+web server, a Fluid host uses the loader to request a [Fluid container](./containers-runtime.md) from the Fluid service.
+
+## host responsibilities
+
+A Fluid host creates a Fluid loader with a URL resolver, Fluid service driver, and code loader. The host then requests a
+Fluid container from the loader. Finally, the host *does something* with the Fluid containers. A host can request
+multiple containers from the loader.
+
+![The loader architecture and request flow](/docs/concepts/images/load-flow.png)
+
+We'll talk about each of these parts, starting with the request and loader dependencies, over the next sections.
+
+## Loading a container - Class by Class
+
+Let's address the role of each part of the Fluid loader and dive in to some details.
+
+### Request
+
+The request includes a Fluid container URL and optional header information. This URL contains a protocol and other
+information that will be parsed by the URL Resolver to identify where the container is located.
+
+This is not part of instantiating the loader. The request kicks of the process of loading a container.
+
+### URL Resolver
+
+The URL Resolver parses a request and returns an `IFluidResolvedUrl`. This object includes all the endpoints and tokens
+needed by the Fluid service driver to access the container.
+
+An example IFluidResolvedUrl includes the below information.
+
+```typescript
+const resolvedUrl: IFluidResolvedUrl = {
+    endpoints: {
+        deltaStorageUrl: "www.ContosoFluidService.com/deltaStorage",
+        ordererUrl: "www.ContosoFluidService.com/orderer"
+        storageUrl: "www.ContosoFluidService.com/storage",
+    },
+    tokens: { jwt: "token" },
+    type: "fluid",
+    url: "fluid://www.ContosoFluidService.com/ContosoTenant/documentIdentifier",
+}
+```
+
+You may notice we are mimicking the DNS and protocol lookup a browser performs when loading a webpage. That's because a
+loader may access containers stored on multiple Fluid services. Furthermore, each Fluid service could be operating with
+a different API and protocol.
+
+### Fluid service driver (DocumentServiceFactory)
+
+The loader uses a Fluid service driver to connect to a Fluid service.
+
+While many developers will only load one container at a time, it's interesting to consider how the loader handles
+loading two containers that are stored on different Fluid services. To keep track of the services, the loader uses the
+protocol from the resolved URL to identify the correct Fluid service driver for the Fluid service.
+
+### Code loader
+
+The loader uses the code loader to fetch container code. Because a Fluid container is a app logic and distributed state
+we need all of the connected clients to agree on the same container code.
+
+### Scopes
+
+Scopes allow the container access to resources from the host. For example, the host may have access to an authorization
+context that the container code is not trusted to access. The host can provide a scope to the container that federates
+access to the secure resource.
+
+## Handling the response
+
+The Fluid loader will return a response object from the request. This is a continuation of our web protocol metaphor,
+you'll receive an object with a mimeType (e.g. "fluid/object"), response status (e.g. 200), and a value (e.g. the Fluid
+object).
+
+The host is responsible for checking that this response is valid. Did the loader return a 200? Is the mimeType correct?
+As the Fluid Framework expands, we intend to make further use of these responses.
+
+The host can then use [feature detection via IFluidObject](./feature-detection-iprovide.md) to query for features and
+then integrate the container into the application.