Hippo is a platform where users can deploy and serve applications written in WASM. The presumed framework for application authoring is WAGI; the tentative assumption is that applications are stored in a Bindle repository. An application may require assets over and above the WASM binaries, such as images or stylesheets. We need to define how Hippo thinks about the assets that make up an application, how it stores them, and how users upload and manage them in the user interface.
The current assumption is that at the database level a Build will simply refer to a Bindle URL; it should not have to care how the assets got into Bindle.
There are two key workflows to consider:
- Production (including staging, gradual rollout and other 'controlled' phases of deployment) - when a set of source artifacts has been committed to version control, and has been blessed to go forth.
- Development - when a developer is working on a fix or feature and wants to make sure it works correctly on the Hippo platform.
Production
The production workflow is fairly simple. The project can have a CI workflow (such as a GitHub action) which uploads the assets (parcels and invoice) to the Bindle server and then creates a Hippo application build that references the Bindle URI. We can scaffold the GitHub action using yo wasm.
The main issue here is knowing which files to include in the bindle. This is also an issue for the developer workflow and we'll come back to it.
Development
The development workflow is trickier. It needs to be:
- Fast enough not to be interfere with the inner loop
- Repeatable enough not to be error-prone
- Simple enough not to interrupt flow
What we don't want:
- Having to manually upload potentially dozens of files, and assemble them into a bindle, every time they do a test build. (This doesn't mean upload by hand shouldn't be an option. But it shouldn't be the only way.)
- Having to push to GitHub on every tweak you want to test.
Perhaps the ideal UI for this is more like the old Visual Studio “Publish” command, which built your Web application and deployed it to a server. This was integrated into the development environment, and did not require a commit or any per-publish configuration. But Visual Studio knew what ASP.NET applications looked like; we don't know how to build user apps or how they're laid out.
QUESTION: Could we mandate the layout and build structures e.g. assets must be under X directory, modules must be under Y directory, building must be via a make build command? Some of this could be hostile to environments that have their own conventions and tools.
Suppose we have a bill of materials that tells us what assets are needed in an application build. Then we can consider three stages:
- Build the modules (and any non-module assets such as Sass -> CSS) - this is language-specific.
- Publish the assets as a bindle. This will do much the same as the GitHub action – we could drive it off many of the same tools.
- Create a Hippo build that refers to the bindle – this is the same as in CI.
A VS Code Publish task could combine those three stages, and could be scaffolded by yo wasm just as the current Build Wasm task is. The BOM could also be used in the GitHub action rather than the user having to maintain that separately.
This does have the implication that every test build gets pushed to a Bindle server, and since Bindle servers are never allowed to delete anything, this could lead to unwanted cruft. It could also make the versioning process tedious for a developer performing a rapid iteration. But we don’t want Hippo to have to maintain a parallel object storage mechanism.
QUESTION: Should we lobby Bindle to support a "dev mode" in which bindles can be overwritten or deleted? If not, should Hippo provide temporary, disposable Bindle servers for dev builds?
What might a BOM-based workflow look like
Imagine, then, that we define a HIPPOFACTS file (short for Hippo artifacts, roughly similar to a Dockerfile, but by convention would also include interesting facts about hippos). This could contain glob patterns for all the assets constituting the application bindle:
# HIPPO FACT: The closest living relatives of hippos are whales and dolphins
[invoice]
package/invoice.toml
[parcels]
modules.toml
out/todo-app.wasm
images/*
styles/*
Or it could be a bastardised invoice.toml but with things like parcel sizes left off, and permitting globs in place of names (that would be expanded in the generated invoice), and with wildcard versioning (so a user could keep redeploying and we would just add incrementing patch number or +timestamp or something), etc.
In either case, the HIPPOFACTS file could be scaffolded by yo wasm, but would have to be maintained by the user.
Then the Hippo deployment workflow would be
- Build from source
- Run a bindle publishing tool that read HIPPOFACTS and uploaded the invoice and parcels
- Create a Hippo build object pointing to the created bindle
Profit Test
This could be encapsulated by a VS Code task for dev and a GitHub action for production; both could be scaffolded by yo wasm.
Authorisation considerations
This workflow assumes the user has permission to upload directly to the Bindle server. This may be considered undesirable; the PaaS operator may want to gate all uploads through Hippo to verify that the user has permission to upload builds for this project. This could be addressed by having the publish tool send a tarball to Hippo which it authorises, unpacks, and validates, and then creates the bindle itself.
We need to understand and capture the usage scenarios and requirements around this.
UI file management
What does this mean in terms of Hippo UI file management requirements? It means probably the only case we have left is the super simple “one or two files”. For this, we can synthesise a bindle with the uploaded modules as the only parcels, with bindle name and version inferred from the build. This would be of limited use for all but the simplest one-off configurations though – hello world, spiking out ideas, etc.
Prioritisation
How we prioritise this probably depends on our demo cases. We could get something ultra-simple going in the UI, but having only that could limit what we do in our demos (because you would not want to show more than a very few files). I feel we are better off prioritising a tool-based approach if we have resources, but it's likely to be more effort than a quick web upload form!
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent