TL;DR
Tailscale, Massdriver, and maybe some DB branching tech like Supabase/Neon/Planetscale offer.
FE + BE separated apps aren’t “easier” to scale though, Vercel is just doing a lot of the heavy lifting.
Please skip if this isn’t useful
I have found, as far as “how” people work together in LV, it’s very fairly standard. Things can be abstracted to components, slots. The components can be “higher order”, stateful, or lower-level and just display oriented.
The testing tooling is quite nice though. It’s generally much easier to modify/refactor a LiveView without even needing a manual QA step, because the tests are able to programmatically cover what might be too difficult to test in another approach, or would require more “waiting” statements.
To the meat of your question. What about previews, or when you just need to update the visuals, but not the rest of it.
I don’t know of a way to resolve this except with infrastructure or tools. But if you think about it, that’s what Vercel is doing for you.
Thankfully there are options/approaches though that don’t require you to go “Full Terraform/OpenTofu”
For local development tooling: My last place we started using tailscale for parts of it, and were able to set some things up that made collaborative pairing very nice.
We could be in a vscode liveshare, or a tmate connection, but then using tailscale to each be connected to the app running on someone’s laptop/devcontainer. And we’d both get all the benefits as if it were just running locally for each of us. It was fantastic. Then you could tell your PM or whomever to go to your tailscale address (e.g. peter.mysillytailnetname.ts.net) and they could give feedback on an actual running instance. I miss it daily
For middle-ish size teams on a budget: you need a little bit of infrastructure, but it’s not too bad. If you wanted you could define preview environments that connect to a shared database, and just only generate a preview if there’s no database migrations.
Ultimately though, you at some point, have to consider the need for either “database branches” features, like on Supabase, Neon, or PlanetScale, etc, or some other functionality for segregating your PR preview environments.
For larger teams:
You probably want preview environments stood up for each PR, and reasonably robust seeds. For a QA environment, you probably want an environment similar to the preview env, but w/ a recent restore.
These aren’t that difficult. You’d need something like a docker-compose for the preview environments, and some terraform, and a way to run that terraform on GitHub triggers (probably massdriver or something if you don’t have something already).
Recent restores for QA is probably more difficult, but not by much.
Maybe there’s an equivalent of Vercel for Elixir preview environments. I’m not sure. Database branching is the main tricky bit, assuming you need it.
All in all though even if this were a FE-only app, you’re still interacting with an API that’s capable of making changes, and if your preview is making POST calls based on bad data, or causing changes in a shared DB, you either have to be okay with those not being cleaned up, or you need a way to set it back to a clean state.
In my experience though, the same way a bad FE change doesn’t mean the backend is going to allow it to propagate, a bad/messy LiveView doesn’t mean it’s going propagate past the Context, or wherever you’re defining your interface.
You still have an API, it’s just in 2 modules/files instead of 2 apps.
