Continuing on from our review of the project’s end goal, let’s sketch out the architecture for the frontend, with a focus just on local-only functionality. Keeping things as simple as possible, I want a text field that we can edit, and which will persist our changes across reloads of the page. Lucky for us, automerge has a tutorial that does just that. Since we’ve sorted out our build system, nothing there should need to change, and whatever functionality we get locally during development should be the same after deployment (though the state will be different for both).

In our previous post, Serving up Fulcro, we learned about what it takes to build and serve the frontend assets for our app. At the end of that post I listed out some Next Steps, but before we pursue those next steps I want to step back and revisit the end goal to make sure that the next thing we figure out is the right next step. In the AutoFlare Overview post I talked about wanting to learn about three things:

Now that we understand the general requirements for hosting FE assets and backend functionality with Pages, let’s figure out how to get that working with Fulcro. Pages has a long list of supported frameworks, but, perhaps unsurprisingly, none of them are a CLJS framework. Luckily, remembering from the Pages overview post, we can either build the assets ourselves and commit them to our repo, or, possibly, we can specify a custom build command that will build the assets for us as part of the Pages infrastructure.

My core goal with this post is to break down how Pages, and Pages Functions, work together. Pages This link has a good overview of how to set up Pages for deployment. The two that interest me are the Git provider set up, and the wrangler cli. My default is to use the git provider configuration, as I’d like to deploy this on push to the main branch, but the wrangler cli may have some useful functionality to learn about.

To host this app, I’ll need the following things: Something to host the static assets, e.g. the html/css/js. Something to handle the state synchronization across clients To host a site that would allow for multi-user alteration of the content, static assets alone won’t be enough, as we’ll need a way to synchronize our changes across users. While automerge has many ways to exchange changes – essentially anything that can faithfully transmit or store binary data – if we want an always-on node that can act as a post-office of sorts, we’ll need to build the code that takes the binary data and puts it on that node.