Deploy and run your own Fluid Framework service
Building and running an app built with the Fluid Framework on your local box is fun. But what’s really fun is deploying these to a Fluid service and then sharing them with others so you can collaborate together at lighting fast speeds! Cooler yet is then being able to embed these apps in any page that has the Fluid loader. But we’ll save that one for a later post…
TL;DR
helm repo add kurtb https://kurtb.github.io/charts
helm install --set host=tinylicious.yourhost.com,clusterIssuer=letsencrypt-prod tinylicious kurtb/tinylicious
helm install --set host=gateway.yourhost.com,key=jwt_signing_key,clusterIssuer=letsencrypt-prod,tinylicious=https://tinylicious.yourhost.com gateway tinylicious-gateway
https://gateway.yourhost.com/my-id?chaincode=@kurtb/canvas@0.1.0The Fluid service was designed to be extensible from the very beginning. When we first started the project in 2016 the plan was always to open source it. And because of this we made sure it had the right hooks to be useful and extensible by the open source community.
A Fluid service is comprised of two main parts: ordering and storage. Ordering is responsible for creating the totally ordered log of inbound messages. Storage deals with saving snapshots of that log.
In Routerlicious, the reference implementation, our preferred means of doing the above is with a set of micro services or lambdas on top of powerful open source projects. Kafka serves as the backbone of our ordering implementation. And we use Git for snapshot storage.
But to the service these are accessed via a set of high level driver interfaces. This has allowed us to plugin multiple different implementations. You can instead choose to order with Kineses, EventHub, NATS, Pulsar, etc… or store your files to GitHub, GitLab, SharePoint, OneDrive, Google, Dropbox, etc… As long as they can implement the driver contract you’re free to choose whatever works best for you.
If you want to deploy and run your own Fluid service you have two ways of doing this: Tinylicious or Routerlicious. Helm charts exist for both that make it easy to deploy to your Kubernetes cluster.
Routerlicious, as described previously, is comprised of multiple microservices backed by Kafka, Git, as well as Mongo and Redis. It’s designed to scale to very large traffic demands. Tinylicious on the other hand places everything inside a single container. Its ability to scale isn’t nearly as good but it’s much simpler to get started with.
For this first post we’ll start with Tinylicious. Before you get started you’ll need a couple things
- Helm
- A Kubernetes cluster with ingress setup as well as cert-manager for SSL certificates. Ingress/cert-manager aren’t strict requirements but currently the helm charts assume this
Once you’ve done that getting tinylicious up and running is easy. Just make sure to change the host and clusterIssuer variables to yours.
helm repo add kurtb https://kurtb.github.io/charts
helm install --set host=tinylicious.yourhost.com,clusterIssuer=letsencrypt-prod tinylicious kurtb/tinyliciousAnd with that you have a working Fluid service!
The Fluid service just deals with ordering and storage. To actually view and create Fluid apps you need access to a host. The host is responsible for authenticating users, generating authorization tokens to the Fluid service, as well as providing access to the Fluid loader. The loader is a small chunk of code that makes it possible to load any Fluid app. It knows how to translate a URL into the necessary network calls to connect to and boot a Fluid app.
Inside of the Fluid Framework repo is a service called Gateway which does just that. It’s a little heavy weight for Tinylicious though so I made a simpler version called tinylicious-gateway. It’s a simple express server that webpacks the Fluid loader.
Installing it is easy. As before make sure to update the variables to match yours.
helm install --set host=gateway.yourhost.com,key=jwt_signing_key,clusterIssuer=letsencrypt-prod,tinylicious=https://tinylicious.yourhost.com gateway tinylicious-gatewayAnd with that you can start loading and sharing Fluid apps!
Just navigate to https://gateway.yourhost.com/my-id?chaincode=@kurtb/canvas@0.1.0 and you’ll have a collaborative ink canvas. If you want to make a new one just change my-id. The ?chaincode query parameter is only required the first time you visit a new ID. It defines the NPM package that holds the code for the Fluid app. A special operation is placed in the log that defines these code packages. But more on that later…
For some other packages to try loading check out the list below. Or of course follow the docs on http://fluidframework.com/ to build your own.
