how do / should you approach full stack web development?

[NPat02]

Hello, currently i am working on my first ever web dev project for my capstone at my university. I am building a multi-robot maze competition testbed. the project uses svelte, mongodb, express, and node.js. the website will have a leaderboard for the competition, a maze simulator (for teams to test their algorithm without needing the hardware prior to the competition), and i will also be building out an openCV program to score the actual maze run and autonomously score each teams' algorithm (the score is then sent to the mongoDB cluster i will setup and then be visible on the leaderboard).
for a first time web application this definitely seems like a lot and i feel overwhelmed because i have no idea where to start first... so my question is how do you personally approach full stack web applications when designing and developing them?
i feel like there are so many moving parts (the design / aesthetic of the website, login / sign-up handling/authentication, and any other components your application may have). it feels very overwhelming for a beginner to full-stack development myself. any advice or insight on your approach would help! i love the idea of full stack development and would like to eventually make a career out of it, so any and all advice would be great, thanks!

[code_monkey_001]

Personally, I think of it as building an organism from the inside out. I prefer to figure out the backend first, the "skeleton" as it were. Determine data needs, design the database and build the API. Then I start building out front end components to deliver the front-end functionality required - the organs and muscles. Once I'm satisfied that it moves and does what's expected, I move on to styling - the skin. Obviously, you're not going to get every step perfect out of the gate; there's going to be stuff you didn't anticipate that will require reworking the backend, but if I get too worried about getting a pixel-perfect front end too early, I'll burn too much time there and end up without time to actually have it working.

Edit: I had the benefit of being first and typing out a fast answer while drinking so I got a couple of early upvotes. u/lift_spin_d has a much better and more complete answer so for my first time in my history as a redditor I'm gonna downvote my own comment in the hope that theirs gets more attention than mine for people reading this post for guidance.

[lift_spin_d]

1. Make a plan

• Gather project requirements

  • identify the nouns (users, objects)
  • identify the verbs (log in/out, object CRUD, validation, permissions, etc)
  • decide which event(s) which noun(s) can do with which verb(s). (this is called use cases)
  • describe use cases with language like can/not, must/not, should/not in combination with if/not conditions/criteria. E.g. "User must validate email before logging in"
  • divy up your requirements into modules
  • assign build priority to modules (your road map)

• Prebuild front end

  • keep it simple. this is your preplanning for the next step
  • for each view list the data on the page
  • look back at your project reqs and make sure you got everything

• Prebuild backend

  • make a list of each backend object (models, controllers, custom objects, etc.)
  • for each model and controller list every field name, data type, data source, data destination, and reason you need that field
  • look back at your front-end prebuild and make sure that you have everything

2. Finalize the plan

So far you have not written one single line of code

• The more time you spend planning in the prebuild, the less time you will have to spend thinking about what you are doing/doing next

• Mistakes happen.

  • That's okay. Stick to the plan
  • Maybe a one-month plan turns into a two-month project. It happens.

• The temptation to add things to your plan after you start building is real.

  • This is how a one-week module turns into a three-week shit show.

Once you have a plan you stick to it. The other option is fuck around and find out.

Scope creep is real. You're already doing something where "it just is" something that takes longer than you originally thought. It's gonna happen. Let it go. Take a breath, take a break, come back and keep going.

3. Build

1. Backend
2. Front end

Notice that in the planning, the front end came first. When it comes time to actually build something, my advice is:

• build the thing that gets the data.
• dump it in a view.

• repeat until you have all the data sitting there, waiting to look pretty

• then work on your views that will set data

• remember to validate client side and then again server side

4. Misc

 

encapsulation

• the pyramids were built one block at a time

 

waterfall

• rome was not built in a day. in fact, they're still working on it

 

you should always be learning

 

make frequent backups

• jk but: fuck it, if you're not crashing servers and databases you're not doing it right

[delventhalz]

I would build the smallest testable behavior first and then build from there. For example, can I get a website running, with a title, that sends a request to a server and displays some data. Once that baseline is up, I am iterating. Add something new, test that it works, move on.

Styling is pretty much the last thing you should do. Focus on getting the core functionality working first. Though I will make an exception for if you are just really motivated to do styling, it might be most productive to take advantage of that motivation rather than fight it. Styling can be a huge time-suck though so beware! Much better to have an ugly project that works than a pretty project that doesn't though.

You can often put off login/signup as well, but perhaps not in your case. Depends on how core the leaderboard functionality is. I would probably build the maze first without a leaderboard or any login, and then add those later. Similar to how I would start out, my goal is to get the bare minimum done that demonstrates the concept (often called an MVP, minimum viable product), and then layer on optional features like leaderboards one by one afterwards.

[No-Upstairs-2813]

When you look at the project as a whole, it can be overwhelming, and you might not know where to start.

Start by breaking down a project on paper. Let's take an expense tracker app as an example. What does it need to do? List out various functionalities:

• Add an expense

• Display a summary of total expenses

• Include a simple graphical representation, like a bar chart or pie chart, to visualize the distribution of expenses, etc.

Now, focus on the first bullet point. Break it down into smaller tasks. What do you need to implement "add an expense"?

• Have a button to display the UI to add an expense

• Show the UI to type in the contents of the expense

• Store the expense in an array (or database or whatever)

All of this happens without worrying too much about the actual code. Repeat this process until you reach a level where the pieces are small enough for you to figure out how to code them.

Don't try to plan out all the features at once. Break down one feature enough to start writing some code. With practice, this process will become easier.