Backend or Frontend First?

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

Comments

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

[Luca Knaack]

Thats a nice approach!
Gonna go with that.

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

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

[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).

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

[Kwabena Bio Berko]

Cool!

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

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

[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).

[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" :)

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

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

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