loading...

Backend or Frontend First?

kwabenberko profile image Kwabena Bio Berko ・1 min read

Do you prefer to build your frontend or backend first? Any advantages? Any disadvantages?

Discussion

pic
Editor guide
Collapse
lexlohr profile image
Alex Lohr

It doesn't matter what comes first if the user is the top priority. I've seen many projects fail because the needs of the user were not considered when building the Back-end first and once the Front-end was started, it was too late.

The projects I liked most had both parts started at the same time and every question was seen from a user perspective first.

In any case, the most important part was Front-end and Back-end developers first agreeing on a common goal and then a shared API between them.

Collapse
kwabenberko profile image
Collapse
juanmaaguero profile image
Juanma

Depends on the importance of the user interaction. If the project is user interaction heavy, then it's always better to start from the Frontend. Because in the successive iterations you can test that UI and make some tweaks and improvements.

But, if the project is about something with very few user interactions, like a reports view, or a streaming based project, then it makes sense to start from the Backend.

Collapse
yordiverkroost profile image
Yordi Verkroost

In the end, it's all about planning and collaboration between the frontend and the backend. Taking time to plan new features and discuss the data transfer objects that will travel between the front- and backend will solve most of the theoretical issues.

If you would decide to build the frontend first, you can always use a tool like Swagger to have a temporary dummy API the frontend can communicate with.

Collapse
leightondarkins profile image
Leighton Darkins

I was just about to write a response with this exact sentiment. For me, it's all about defining a contract between the two early, then building to fulfil that contract.

Once the contract is in place, I don't see a significant advantage or disadvantage to starting on either side of the fence.

My go-to tool for creating dummy APIs is json-server. It's much less feature-rich than Swagger, but also much more lightweight.

Collapse
ninoskopac profile image
Nino

If you wanna go ever more lightweight, you can paste your JSON on Gist and then just link to that (get the URL via the "Raw" button on top right).

Collapse
nijeesh4all profile image
Nijeesh Joshy

as a full stack developer
I make a fake back-end first which will give me a fake desired Response in required format. Then parse it on the front end then properly organize it style it and add the front end error handling. Then i go back to the back-end and finishes it.

Collapse
sithhades profile image
Luca Knaack

Thats a nice approach!
Gonna go with that.

Collapse
jillesvangurp profile image
Jilles van Gurp

Launch early and do both. Then you are going to get it wrong, so iterate and focus on figuring out mutual requirements, pain-points, and integration points.

Doing one or the other first just means you delay the moment where you find out how wrong you got it. Build a prototype UI with a functioning backend as early as you can. It doesn't have to be pretty but it does need to be functional.

So, figure out some MVP with both frontend and backend covered that is demoable/usable enough to plan further steps.

Collapse
aghost7 profile image
Jonathan Boudreau

I try to build the backend and frontend together by breaking things down into multiple features that are implemented incrementally. You can always go down the wireframing approach, but I've seen design issues arise when you don't start with proper data modeling (ie, how you store your data).

Collapse
lukebearl profile image
Luke Bearl

I do fullstack, and have always found it easiest to build the backend first. The big advantage of doing it all fullstack is that if/when something is identified that was overlooked, the one dev doing it all can make the necessary changes (disclaimer: most of the stuff I work on is traditional MVC, so the frontend and backend are somewhat intertwined, as opposed to having a full out JavaScript client application which exclusively communicates over APIs).

As a few of the other folks who have answered have said, if you have dedicated frontend and backend teams, then more planning up front probably will save a lot of churn going forward.

Collapse
bousquetn profile image
Nicolas Bousquet

I learned to design the system from the user and so UI point of view. What are the interractions the user would have with the system. Most often they are through a frontend, in particular for web app, even if sometime there can be mail, SMS or other things like that.

There mostly need to design/implement a backend that can respond to actual frontend queries. There no point to implement backend feature that nobody would ever be able to use because there no way for the user to ask for it or display the result.

I would not implement a full frontend without backend or the contrary. I'll get the most important feature for the client (based on his priorities), deliver it, gather the feedback and iterate. So likely, that would involve doing both at the same time.

Collapse
ritchieeinstein profile image
Ritchie Einstein

I am a full stack developer for a while and from my experience, it is totally dependent on the nature of the project. If the project is well defined before the beginning of development, then I would suggest for a Backend First approach. Since we have a clear picture of every module.

But rarely that happened to me. Mostly my clients prefer to analyze the business requirements for the next module based on the current module that I develop. In that case, I go for a mixed approach. Dev on Both front and backend simultaneously. To give advantage to the client, I'll develop the front end first, that way they can come up with more refinements on the data to be collected and how it needs to be displayed, and I can implement the backend accordingly once and doesn't need to change much.

But trust me, if you follow this approach, your code needs to be agile as much as possible and (as my architect quotes it as ) "Embrace the Change" :)

Collapse
patrickgordon profile image
Patrick

I prefer to define my API schema contract first.

I do this by using something like json-server to create a "fake API" endpoint. I can then use these mocked out endpoints to build my front-end.

I find that building the front-end often leads me to think about what data I need to display and that lends itself to updating the mock, and then, in turn, informs what's required when building the backend.

Collapse
jlehew profile image
John Lehew

Front end first can work if the developer checks the schema that is generated but most devs I’ve seen never check and accept whatever is generated. Even if they checked, many do not have the experience needed to properly evaluate the schema generated. This in combination with the fact that tools do not always refactor the database schema and data correctly lead to bad designs and lost data.

The method I follow after designing 16 systems from scratch in my career consists of iterating over the the back end design, the api calls, and high fidelity mockups with the users until users agree with each other and the design stabilizes. The backend, api, and front end must be continually reviewed and kept in sync with requested changes by both the users and senior dev team members. Once the design stabilizes it becomes a guide and the system is built using agile principles. It is critical to understand that the original design is not a contract, it is a guide. This process educates the team on the business processes, clarifies the language everyone uses to describe system functionality, and refines the core design of the system.

Collapse
gleidsonthuller profile image
Gleidson Thuller

Together. Mainly If you're going for a microservice approach, they definitely should come together, respecting your definition of done and possibly be a MVP. All this to reduce feedback cycle and avoid overengineering ;-)

Collapse
sergiodxa profile image
Sergio Daniel Xalambrí

I like to first define the API and then write both at the same time. This is common when using GraphQL because you can use the Schema-first approach to define the GraphQL schema and then work Frontend and Backend at the same time.

With a REST API you could use something like Swagger or just define a README.md with the API endpoints.

Collapse
adamt213 profile image
Adam Tropp

I have always tried to backend first, but for the first time recently I came across a project where I did not have a clear idea of what API endpoints would be needed until I saw the user's perspective. Frontend first haf never occurred to me, but having a reasonable sense of what the ui should like before getting too deep into the backend now seems like a reasonable strategy for a lotnof projects.

Collapse
inmsadarsh profile image
Collapse
nerdial profile image
nerdial

both at the same time ...