What to build first frontend or backend?
So I am working on one of my side gigs which essentially is trying to streamline processes for financial analysts (landing page: https://www.memofi.co/) when I picked up an amazing design book called "The Design of Everyday Things" by Don Norman and started reading about designing your product in a Human-Centered way.
Human-Centered Design (HCD) focuses on the person that you are building the product for, therefore, a big part of it is actually watching a user perform the task you are trying to streamline, then building a prototype (wireframe) from what you've learned and watch the user interact with that. Then iterate.
This makes me think that you would focus on iterating the frontend (not fully building it out but using some sort of prototyping tool) and then implementing the frontend code, followed by the backend code.
My worry is that if I start with the backend code, and then ideate/iterate on the frontend the endpoints/business logic that I will need will change.... which is why I am asking for some help here!
Side note: anyone know of a really good high fidelity prototyping tool?
I would stick myself to a paper or blackboard even before creating the frontend or backend. With over 10 years as a full stack developer, I would rather cling myself to basics.
My idea of development through any project should have sufficient planning that is not on a computer. I have once heard that 80% of the entire product development lifecycle is analysis and design on a paper. The number could be less.
When we take an example of directing a movie, all the scenes that need to be filmed are first written over a paper. That way any scene you direct, you know where it needs to land.
Writing pseudocode helps. Algorithms and Flowcharts are my favorite tools. I still use them.
Once you have developed a plan, you will have an idea where you need to start. How both frontend and backend can be linked.
All the best in whatever you are trying to achieve.
One slice at a time: https://basecamp.com/shapeup/3.2-chapter-10#integrate-one-slice
absolutely that. But also, read up the whole book. It talks about "shaping" as a way to actually figure out what is it that you're planning to do WAY before any front/back end work.
That's how you start; paper or blackboard, like @reubenraj said.
this was super helpful
Agree with @jator above. I typically develop the front end and the backend at the same time. I prefer to see how things are coming together as they’re being built.
I'm doing a mix of both. Front + backend.
First I do a sketch of how I want the app to look, and then start working on some basic features and build the front end further based on those features.
I noticed that for me at least, breaking the pattern and switching from frontend to backend works better and takes the monotony away.
Also, if there are things that don't work, switching from one task to the other, can help you get a new perspective on the issue and find a fix.
In my opinion, the backend and frontend should be developed together. However, neither should be done until a solid design phase has been completed. I've found the front and backend work together to provide the business logic value together. It's rare for a product to be able to develop an MVP without the backend to support it.
However if there exists some tool to allow you to spoof one specific workflow in a sound way then I'm all for it.
I've found that developing them in parallel has been most useful. I completely agree with one slice at a time. I'm a MERN + TypeScript developer and as an example of how I've found this useful:
Can't forget the basics either; mockups and process flows on a piece of paper can go a long way