What is the ideal workflow between backend and frontend teams when you have short deadlines?

when you have short deadlines?

Ideally you have a consistent sense of deadlines, i.e. if they are always short, at least we know it's quick cycles and expectations can be tailored to that.

I think you could go either way: Clear ownership for parallel work or make it clear that everyone is effectively full stack (even if some have more specific expertise).

I think if you are not clear which of these scenarios you're playing with — that's where you run into trouble.

I think the most important part here is that the entire dev team should agree on how the back end will communicate with the front end.

They should agree on what the API will look like. It should be something that's both achievable for the back-end team and useful for the front-end devs.

The old "good, fast, cheap - pick no more than two" cliche comes up here. If the deadlines cannot move and the project plan is ambitious, I might be tempted to cut something from the scope. If this option is taken off the table, then quality has to suffer. The site will be bodged together and will be more difficult to maintain in the long run.

But perhaps the answer is to have a cookie-cutter solution - clients are offered a very limited number of options for their product and deviations from this are eye-wateringly expensive. As a result, the development of the features is more like assembly and skinning than bespoke development. But perhaps I'm missing the point and the answer is "Agile".

Agree on the shared contracts between the two teams: input requests and responses for example. As an option, the backend team can create an endpoint (following that shared contract) that returns a hardcoded response while they work on the right solution.

Your topic is very interesting. If you follow the code-behind pattern, you can get better results. The stronger side must provide documentation of the interaction to the other side. If the pages are rendered on the back-end side (traditional approach), the documentation should be done by the back-end team. Also, if the number of pages is on the back-end side (using front-end frameworks), the documentation should be done by the front-end team.

Server Render Example: Back-end developers document the names and values ​​of transitions.
For example:

@model.Title is the title of the post.

Client rendering example: Front-end developers document a JSON template.
For example:

{ "status": "success", "message": "Request processed successfully", "data": { "id": 1, "name": "Example Item", "description": "This is a simple JSON example from the server.", "price": 19.99, "available": true } }

We have thought a lot about workflow!
We at Elanat have tried to separate back-end developers from front-end developers by providing innovative features in the CodeBehind framework. This separation makes each department do its work separately.
As it is clear from the name of our framework, during the development of the CodeBehind framework, we have paid a lot of attention to the code-behind structure.
In the link below, you can see the Return Template technology belonging to the Elanat team.

• youtube.com/watch?v=zUftrftUCtw

In Return Template technology, back-end and front-end development are separated even in the strictest conditions.

Also, we have added the WebForms Core feature in the CodeBehind framework. WebForms Core is a new technology where HTML DOMs are controlled from the server side. Of course, the server only sends command codes and the codes are interpreted and then executed on the client side.
Video of how WebForms Core works:

• youtube.com/watch?v=Yp4vQ_lEd_8
• youtube.com/watch?v=ZuMMApM00xM
• youtube.com/watch?v=zl4sxjIkBwU

Ideally you want to get one endpoint up and running end to end as soon as possible, preferably on a shared sandbox.

This takes care of most setup issues that you would run into later into the dev cycle.

After that's done, define contracts for all APIs clearly - usually BE takes ownership of this on fat server - thin client setups, but if yours is the other way round then FE will define the contracts. Both teams should make sure that the contracts are 90% there.

You can request the FE team to use Postman and have a shared collection using which the contract can be verified during development and consumed easily.

Make sure FE has a mock server setup or the ability to mock XHRs to speed up development easily. MSW is pretty useful for this.

This is the workflow from my previous company that the absolute chad move is to start with solid API contract design before anyone writes a single line of code. We were getting both teams in a room (yes, no remote), and hash out the API specs using Swagger. The frontend team can start building against mock data immediately while we backend enjoyers do our thing.

Then, implement feature flags everywhere. This lets you ship partially completed features to prod without causing a dumpster fire. BE team can gradually roll out endpoints while frontend can build and test against the completed ones. Also, normalize 👏 having 👏 shared 👏 TS 👏 types (if you're in the TS gang) between BE/FE. Nothing makes me die inside more than seeing FE devs manually typing out interfaces that should've been shared from the backend.

But now, i'm building polymet.ai so the prod-ready react code would become ready when designers handoff the interface.

+1 on agreeing on the interface between the frontend and the backend. I've done this a couple of times recently: using JSON to specify the input and output fields and their expected values/types.