I'm not disagreeing with the architect part -- that's what I meant by "Once you've verified that the API design works for the needs of both ends".
An architect working in a vacuum is only going to result in unmitigated disaster in my experience. :)
But I disagree where you say that it's usually obvious from a mock-up that the backend is going to be too complex. In my experience that never occurs to people at all. All too often I've seen designers spend months mocking up fantasy functionality while the backend team is drawing up tables, shards and microservices, only for it to eventually collide in total incompatibility, when the front-end developers say "but the back end doesn't let us do three-quarters of this!" and the back-end developers say "but obviously you can't get the data that way, what ever made you think you could?"
Forcing the API conversation/specification to happen at the start, rather than in the middle, forces extreme clarity for both sides, so that necessary critical compromises are hashed out at the beginning, instead of discovering a horrible incompatible collision midway through.
> designers spend months mocking up fantasy functionality while the backend team is drawing up tables, shards and microservices, only for it to eventually collide in total incompatibility
that's because this methodology is called waterfall, and it has proven to not work, time and time again.
The project should not start with full requirements - it should start with a single requirement/feature (even if that feature by itself doesn't fullfil the purpose of the software). What is the topmost important feature? Do that part first, and have it working end to end. It should take as little time, and done as fast as possible. It should allow the design team to create as simplified a design as possible, and allow the backend to use as simplified a backend as possible. It should allow testing to be done well (good coverage, good unit testing etc).
Then once this is done, the client will judge it, and say what can be improved. Do that one improvement, only, before going back to the client and repeat.
Obviously this is a complex topic but this applies equally well to agile as well as waterfall.
If you're planning your sprint, the point is to figure out the API call first together, before work starts on either front end or back end.
Real-world projects exist on a wide continuum between "maximum agile" and "maximum waterfall", and usually fall somewhere in between. You can't build AWS or Google Search purely out of 2-week sprints with no further advance planning or specification. :P
An architect working in a vacuum is only going to result in unmitigated disaster in my experience. :)
But I disagree where you say that it's usually obvious from a mock-up that the backend is going to be too complex. In my experience that never occurs to people at all. All too often I've seen designers spend months mocking up fantasy functionality while the backend team is drawing up tables, shards and microservices, only for it to eventually collide in total incompatibility, when the front-end developers say "but the back end doesn't let us do three-quarters of this!" and the back-end developers say "but obviously you can't get the data that way, what ever made you think you could?"
Forcing the API conversation/specification to happen at the start, rather than in the middle, forces extreme clarity for both sides, so that necessary critical compromises are hashed out at the beginning, instead of discovering a horrible incompatible collision midway through.