Senior web developper.
Please i have a question for you

When you want to make a full stack web application. You start by the front-end (design) or the back-end?

If you have to ask that, please know what you're actually building and plan it out beforehand.

Doesn't take a senior for that.

Build in small increments. Aim for MVP first (minimal viable product). Add features one by one, both backend and frontend.

Im not senior but here is my 2 cents; I start with db design. After few iterations of initial db has been created, I continue with back-end project. Initial stuff like simple endpoints (like 1 or 2 endpoints). When Im done with sending simple requests and getting actual data from db with a rest client (or swagger), I start to work on front-end and connect it to backend. After that initial project creations in all layers, I develop by feature. That means developing both be and fe for a simple feature. With this development style, I can detect design flaws earlier. Also it makes refactoring easier. Either its because of a design flaw or requirement changes.

It's entirely optional but I work in an "incremental delivery" format. The last full stack app I built, I used UML diagrams to associate dependencies between the end goal of the system and what would need to be implemented to meet those minimum requirements.

Practically, this ended up with me creating the back-end requirements and testing responses through Postman before moving on to the front end.

I'm not a senior though. Actually haven't even started my first job yet after leaving uni not long ago 😂

In a good design they're decoupled. You design the domain, then the operational data contract, then you build whichever is required most urgently.

you start with thinking and writing a concept paper and some scribles, uml flow charts.

quote:
"If I had 8 hours to chop down a tree, I would spend 6 of those hours sharpening my axe."

And as @gronostaj said build the minimal loveable thing possible. Just enough to make the core functions work and plus some measurements that your thing is pleasant to use.

Never ever forget the user. Don't be that tech nerd who only loves his code and tools and forgets for whom he does all of that.

@odite They teach that at business schools you know

@123username you can't make that shit up!

The front end backend distinction is largely made up. It's all just shit that runs on computers. You build incremental features that work. Which one comes first is irrelevant

Not a senior developer but I prefer starting with wireframing. That helps me get a clear vision of all the functionality my app will have.

Depends on the app.

If the goal is to store data I start with ERDs.

If the goal is to provide a multi-headed or headless service I start with interactors [pseudocode ofc]

I hardly ever start with FE. I only start considering FE when BE idea is almost complete [on paper, not in code] and then readjust all the layers to play nice with FE.

Some developers find it much easier to start test-driven prototyping of MVP - with mocks, fixtures... instead of taking time to make both backend and frontend to see the desired result. You can imagine it as drawing vectors instead of raster - implementing application by defining tests.
Personally, I see it only as productivity boost for already advanced full-stack developer, but it may be useful later on. :)

@hack please what do you mean by refactoring?

@devGaara please what is MVP?

@Afrographics MVP is minimum viable product. It's just a fancy way of saying a product with all the features that seem most important to achieving the main goal of the application you want to develop.

@Afrographics Google it. Refactoring is a common term.

If it's your first project, don't think so much. Just start it. You'll figure out things. You might not start the project at all if you keep thinking.

when you're building a house, do you start by arranging the furniture on the plot and painting the (nonexistent) walls, or do you start by building the foundation and walls and roof?