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:

  • Cloudflare’s cloud offerings
  • Fulcro
  • Automerge CRDT

So far, we’ve learned enough about Cloudflare’s offerings to identify the top-level offerings we’ll need to use, even if we haven’t learned enough about all of them to use them yet.

We’ve also learned enough about Fulcro to build frontend assets with the Pages service, though nothing else about Fulcro yet.

Finally, we’ve learned nothing about Automerge.

At the end of this project, I’d like to have a repo I can deploy with Cloudflare Pages that supports multi-user, multi-machine text editing with Automerge, using Fulcro as the library for handling the FE code.

Since Automerge was built with local-first development in mind, we can distinguish between two major architectural phases of this project:

  1. Local only
  2. Local and Remote

The first phase only requires frontend assets, and thus doesn’t require us to sort out Pages Functions or Durable Objects at all. The second phase requires the same things as the first phase, plus an understanding of Functions and Durable Objects. Even if we were to start with Remote Only first, we’d still have to sort out most of the same things as the Local Only phase – defining the UI, handling text input, leveraging automerge – along with all of the things the Remote phase needs, so going Remote Only as a first step doesn’t save us anything.

With that in mind, figuring out how the local-first approach should look sounds like the next, incremental step in this project.

I’ll sketch out a rough shape for the necessary components needed for this local-only approach in the next post. See you then!