Share on other sites

Most people would probably think that developing the logic to store and fetch data first, and worry about the UI later would be the best approach. But on larger projects I think it's a often a good idea to involve a frontend dev, a backend dev and a designer and have them workout the solutions together from the start. That is the model we use on complex projects at my workplace.

Here is some of the reasons why.

Estimates
A project manager needs estimates and you can't really ask a backend dev what a logo design, or an animation will cost.

Visualizing concepts
The designer is usually better to communicate with the client/external shareholders because he/she can visualize the concepts with wireframes, mockups or moodboards. It is always important to have the concepts visualized, defined and agreed on before any coding starts, so that the developers don't have to rewrite large amounts of code later in the process.

Better code/markup
You can have the front end dev working on the UI and template/view files as soon as the visual concepts are approved by the client. The frontend dev can start by inserting dummy content in hardcoded html or even code functions that returns dummy content (if he/she knows a bit of backend). This can be a big help for the backend dev because, even though the functions would have to be rewritten, the backend dev would have a clear idea about what markup the frontender expects in the returned data.

Better solutions
Many problems have solutions that can be solved in both the backend and frontend domains. How do you find the best solution if your devs do not work together from the start?
Say your backend dev have coded a function that fetches data via a slow external API. But the interface also have a filter function. Lets say a simple show-only-new-content-button. Instead of having the backend dev post back an argument to the function and perform a new slow API call, maybe the frontender could just code a JavaScript function that simply hides the older content when the button is clicked.

Share this post

Link to post

Share on other sites

The whole application should be built as part of an iterative process whereby features are added over time. When building a new feature I'd work closely with design and if possible users / stakeholders creating that feature using mock data to simulate possible server responses - this allows you to figure out what shape the data should be returned from the backend in. GraphQL is really good at this. REST less so, but can still be done by deciding what endpoints return what data.
Once all this has been figured out and the user is happy with the feature then build the real backend for the feature. Perhaps as a standalone service that could potentially be re-used across multiple applications. This puts things in a position where it's possible to scale easily and your frontend doesn't have to implement a load of work-arounds to handle a backend API that was designed too early in the process.

Then you start on the next feature, and so on. Even better you can deploy the app and let real users consume the features you have created and get feedback really early. This is far better than a big bang release to find out that certain features don't actually do what the user intended.

I should also re-iterrate big up-front design is bad. 9/10 aspects of the design result in bad code because the design does not translate well. It's never been tested on real devices with real users before. This whole approval process then moving onto development is what is so wrong with the waterfall approach. Maybe it's ok (to the point where you'd get away with it) for a small brochure website but it's a really bad approach for a complex and costly application. Designs should be done at a component level (Each feature will have a number of components) and they should be designed in the browser with a dev and designer pairing together, and again even better an end user / UX expert.

Back end first if complex. Generally the nips and tucks behind the scenes will dictate the UI requirments, at the end of the day it needs to function first and look pretty / ux later.

I should add that in modern web applications a lot of the business logic is likely to live in the client. How much depends on the application architecture, however there's plenty of applications where all the logic happens in the client and a serverless approach is taken for the backend, which serves little more than to be a data store, a separate service might be used for authentication - but again a lot of the work can still be done in the client.
Gone are the days where the backend has to do all of the business logic.