So, this week I meant to put up the next post in my MERN stack project series, but I realized that I was leaving out a huge part of the project-process by not talking about proper project planning. For most of my projects, especially recently, I've been following a planning process that helps me breakdown the project into component parts that help me build more efficiently.
Here's a basic project planning breakdown:
- Scope
- Database Modeling
- API Endpoint Planning
- Backend Build
- Backend Testing
- Wireframing/Sketches
- Component Planning
- Frontend Build
- Frontend Testing
Below are the questions and elements of each part of the process...
Scope
This step simply involves planning the scope of the project in question. Are you building both a backend and frontend? Do you need to account for user authentication? Will you be using any external/third-party APIs?
Database Modeling
If you've decided to build a fullstack project, what database will you be using? What database models will you need? If you're using a relational database, what relationships do you need between models? If you're using MongoDB, do you have a cluster available to put your collection in?
API Endpoint Planning
You've got your database set up, so now it's time to plan out your endpoints! Do you need full CRUD endpoints for every model? Are you planning to handle query parameters with your API? Which endpoints will be public, and which will be protected? How will you protect those endpoints that aren't publicly accessible?
Backend Build
Time to build!! Are you using Rails, Express, Django, or something else? Where will you host your API?
Backend Testing
Test your code, folks! Build out tests as you go with your testing framework/tool of choice. I also really love using something like Postwoman/Postman or Insomnia for manually testing API endpoints. They let you mock your API calls to make sure your responses are coming through as expected.
Wireframing / Sketches
We made it to the frontend design! 🎉
This step is crucial and is the step I most frequently skip and I always regret it.
Even if you don't consider yourself a designer, sketching out a basic concept layout makes the coding process so much easier. This step is even easier if you're using a UI library like Material UI or Bootstrap, because you can plan out which components/classes you'll use ahead of time.
Component Planning
If you're using a component based framework like React, it's a really good idea to look at your sketches and break them down into components. Where are your containers? Which components maintain state? Can you create a "single source of truth" for your app to keep your state in check? Planning this out ahead of time will save you so much frustration later on.
Frontend Build
We did it, y'all! We made it to the frontend build process!
Even though this is ostensibly the last step, it could certainly be one of the longest.
Do you know which frameworks or CSS pre-processors you'll use, if any? Do you have your fonts, and colors, and style elements chosen? Are you using them consistently? Are you designing mobile-first and for accessibility? If not, you should be!
Frontend Testing
This step is coupled with the prior build test. Write your tests as you go, and make sure you're covering edge cases appropriately. How are you handling errors from a UI perspective? Does your app or site fail well? If not, how can you better handle errors for your users?
User Testing
If you want to be really ambitious, and don't mind sharing your project with others, it's a great idea to get some opinions from users. They might find edge cases you missed, or have suggestions for improving your app that you might be too close to the project to see on your own.
For beginners working on their first portfolio project, this list can feel really long and really intimidating, but fear not! My favorite thing about this list, and this process, is that each step is relatively self contained, and each one builds on the last. And you don't necessarily have to have everything planned ahead of time. Maybe you'll plan out the database and API endpoints, and start on your backend build, before you really start thinking much about your front end. Or maybe you'll design a really beautiful frontend mockup and then plan out a backend to fit into that design.
Either way, planning is your friend! I've only really recently gotten a handle on proper project planning and it's made the process so much more efficient.
I hope this list helps you get your next project finished just a little bit more efficiently!
xx
Emily / TheCodePixi
This article was originally posted on TheCodePixi.dev/blog
Top comments (26)
So true! That's why I mentioned at the end that the order isn't set in stone. Sometimes the frontend goal informs the needs of the back end, and vice versa. Totally valid and sometimes necessary to flip flop the order.
Excellent overview of the planning process, thanks for sharing! I've definitely missed and then come back to some of these later during projects--bookmarking this to look at again for planning my next app!
Yeah I made this partially for future me who knows that past me has definitely scrimped on planning before lol
Just the article that I was looking for! I love how you break down the lists above. From there, I can actually break each of them into smaller chunks for me to be able to get started. Very helpful for me as I am currently working on a project for a friend's online business. Thanks for the tips!
Perfect! I'm so glad it helped you!
The most concise list I have seen. I know it can be overwhelming to even think of a check list for a full stack project, but this list contains almost everything that a production ready app requires. I believe deployment should also be added to this to make it more robust.
Great job. Surely saving the post.
Dev with a plan! Very nice.
Breaking the planning process like this makes it much more comprehensive. Btw, I actually prefer to start the process from designing front end.
I wonder what's your reason to start from backend?
Honestly, I'm just not much of a designer, so I think my brain tends to default to thinking about the underlying system. I think about a problem I want to solve, or what kind of user experience I want to have, then I build the necessary backend for it. Then I try to design a front end around that system. It's actually probably a better idea to design a UI first, and build a backend to fit what the frontend needs.
I'm with you Emily. I've been in the software world for years (that does not mean i know too much or that I'm a true expert). Most of the projects I've been part of started by designing or solving the "source of data" problem, where the data will reside, and the underlying business rules. Way back when, we talked about Databases. Nowdays DDD -> Database -> Backend. By solving them we will have most of the business rules implemented. Then, we should code a front end that even could be required for different types of devices. However, in favor of what Anik wrote above, is a good idea to have a basic prototype, layout, screens, that can help the customer see what he/she is going to get as a software product (at least for the main or critical parts of it)
Cool! Got it. 🙂
I would advise to do these steps per feature (or part that can be developed separately).
This is similar to how your directory structure should look (on the internet they often call it package by feature vs package by layer).
The benefit of going through all of the steps for concrete features is that you get feedback early and get a firm grasp of your actual progress. It also helps you figure out what works and what not for the specific situation saving you tons of rewrite work.
Very nice post! Have you heard of or ever tried Meteor for a MERN stack equivalent? It's kind of a dream! ❤️
Meteor gives you a CLI on top of Node.js that tightly integrates the entire full stack. And you get an amazing build tool (replacement for Webpack or equiv) and real time data connections from MongoDB all the way to the client with pub/sub, which is perfect for multi-user apps where you need client to client updates.
Also instead of using HTTP requests to your own server, Meteor gives you Methods with the simplest API imaginable.
I guess this all comes down to the most productive JS development stack on the planet. So if you like to build things, you spend 10 hrs instead of 100 hrs, or 1k hrs instead of 10k hrs 😀
It gives you mobile & desktop app capabilities too. I turned my web app into mobile & desktop versions via some PWA features in just a couple hours, and Meteor's build system can also effortlessly produce a Cordova web app for Apple & Google stores.
Happy coding!! 🎉
I love this approach too! The front-end really should shape the backend & database structure for new apps in an ideal world. This is natural and why MongoDB is the perfect choice for a database. And this is all even easier in a Meteor app. The most common Meteor front-end (view layer) today is React. Today I mostly use Vue + Meteor for JS app development. It's amazing!
What about security? OAuth2 with JWT? SAML?
Basically, the way you making it is the same as what I was taught in my uni to build a web project. And the lecturer told me, he changed to teaching back-end first since my semester.
I never realized there were sooooo many steps. Well, at least I never broke them down so well. Thanks for explain each part so well! I’ll definitely be coming back to this as a reference
So. Many. Steps. But all of them are totally worth taking the time for.
This is great! I wish more people talked about planning for a project rather than just diving in
Right!? Planning is everything!
I'm glad it helped! I've been trying to focus more on time management and getting more efficient and the planning process is key.
First of all thank you for this it's very informative. Is there any sub steps on each step?
I tried to leave that open ended because that will vary pretty widely between projects based on what you're building and the tools you're using.
Appreciate it!!