I think historically, in many instances, API's and back-end services tend to have be designed and implemented in isolation, with the UI (if there is one) added later. More recently with complex applications I'm finding great value can be attached to having a UI in play even while the back-end implementation is still in-progress. (or at the very least while the rough edges are being removed) This has been a bit of a revelation and I'm pondering "why?
(as in why it can be of value)

It seems to hinge on visibility. My instinct is that starting on the UI before the back-end is complete should result in wasted time, coding for things that will change. However being able to "see" what's going on under the hood can help spot things that unit tests and integration tests can miss.

Prime example number one, I'm working on a control panel for my mesh database replication, so one of the first things in the UI I look at is a reactive display of various parts of a running mesh. In this case a display of all the replica's for each configured topology.

Replica display for a nine-node topology

The first(ish) thing I noticed was that an occasional the "LIVE" marker was occasionally turning to "PING" due to an errant debug timer I'd forgotten to remove. I'm still working out the best integration test approach to pick up on that sort of issue as it's going to need to run over a longer period - although this specific issue isn't likely to happen again.

Next up, I'd left the sleep between monitoring pings at too low a level and although it was working fine, it was using way to much CPU. That one is going to be fun for the GitLab runner. It's pretty slow, so it's idea of high CPU usage is going to be different to mine ..

Same nine-node topology, live "Node" display

Last but not least, I'd configured my 9-node mesh in code (quite some time ago) and had been using it for testing, and it worked fine. But when the visualisation first came up, I thought the display was broken as the map was horribly contorted. Turns out I had an additional connection in there between nodes that shouldn't have been there, which was effectively an error in the test code that generated the mesh. Not sure how you spot that if not by-eye.

Mesh topology display (Live/Reactive) with details for selected Node

I'm kinda kicking myself a little for not starting on the UI earlier as I got stuck on a number of issues this would probably have brought to light sooner. Still .. next time ..

In the meantime, I'm really liking Vue's ability to make a component out of just about anything. The Node display you see above with the CPU/MEM gauges, Network graph, uptime etc, is implemented as one "component" to which you pass a "node" reference, so including it in a page is just a case of including the component, so the "Nodes" page just does;

<div v-for="node in this.nodes" :key="node.id" :item="node">
    <node-chart :node=node></node-chart>
</div>

And that renders the second screen shot.

Next comes mesh editing .. fun for tomorrow morning .. :)