Agreed. So how do you usually go about making changes across frontend and backend as easy as possible?
Often I'd start with the feature I want in the front-end, play with it until I recognize what I need in the back-end.
Then implement the back-end feature first. I'll test it with unit tests, with the exact use-case I need in the front-end. This keeps the two bits separated, meaning it works fine with split repos, even with separate release schedules.
Once the back-end is ready, I'll implement the front-end part of the feature.
If you have one repo for front/back-end this is painless. The more repos you have, the more release pipelines you have, the more involved it can be. You need to ensure the backend support is released before the front-end -- though honestly, that's more of a nuance than significant problem.
Note, I'm not perfect at knowing exactly what the back-end feature is that I need. So I will usually work front/back at the same time until I do, then focus on finishing the back-end feature. This requires your code be able to work with working code from multiple repos -- an essential setup need for multi-repo projects.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.