Do you prefer to build your frontend or backend first? Any advantages? Any disadvantages?
Do you prefer to build your frontend or backend first? Any advantages? Any disadvantages?
For further actions, you may consider blocking this person and/or reporting abuse
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.
Thats a nice approach!
Gonna go with that.
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.
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.
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).
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.
Cool!
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.
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.
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).
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" :)
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.
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.
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.
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.
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.
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 ;-)
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.
medium.com/@adarshsomani64/front-e...
I wrote an article on this topic
both at the same time ...