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

Unfortunately it’s not always possible to have ideal development times, so I was wondering if it is possible to improve the workflow between two teams (backend and frontend in my case), improving the development experience for everyone.

Feel free to share your workflow, articles or just your thoughts.

Discuss!

Comments

[Ben Halpern]

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.

[Cesar Aguirre]

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.

[@whereisthebug]

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.

[Ross Angus]

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".

[elanatframework]

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

[Qian Li]

+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.