A few weeks ago, I came across a developer sharing one of his side projects on GitHub: a Trello clone. Built with React, Redux, Express, and MongoDB, the project seemed to have plenty of scope for working on fullstack JS skills.
I asked the developer, Moustapha Diouf, if he’d be interested in writing about his process for choosing, designing, and building the project and happily, he agreed. I hope you’ll find it as interesting as I did, and that it inspires you to work on ambitious projects of your own!
Nilson Jacques, Editor
Before moving on to the approach, I’ll take some time to discuss how:
I defined my goals before starting the project.
I decided on the tech stack to use.
I setup the app.
Keep in mind that since the entire project is on GitHub (madClones), I’ll focus on design and architecture rather than actual code. You can check out a live demo of the current code: you can log in with the credentials Test/Test.
Defining the Goals
I started by taking a couple of hours a day to think about my goals and what I wanted to achieve by building an app. A to-do list was out of the question, because it was not complex enough. I wanted to dedicate myself to at least 4 months of serious work (it’s been 8 months now). After a week of thinking, I came up with the idea to clone applications that I like to use on a daily basis. That is how the Trello clone became a side project.
In summary, I wanted to:
Increase my ability to architect, design, develop, deploy and maintain an application from scratch.
Practice TDD (test driven development) and BDD (behavior driven development). TDD is a software practice that requires the developer to write test, watch them fail, then write the minimum code to make the test pass and refactor (red, green, refactor). BDD, on the other hand, puts an emphasis on developing with features and scenario. Its main goal is to be closer to the business and write a language they can easily understand.
Learn the latest and the hottest frameworks. At my job, I use angular 1.4 and node 0.10.32 (which is very sad I know) so I needed to be close to the hot stuff.
Write code that follows the principle of the 3R’s: readability, refactorability, and reusability.
Have fun. This is the most important one. I wanted to have fun and experiment a lot since I was (and still am) the one in charge of the project.
Choosing the Stack
I wanted to build a Node.js server with Express and use a Mongo database. Every view needed to be represented by a document so that one request could get all the necessary data. The main battle was for the front-end tech choice because I was hesitating a lot between Angular and React.
I am very picky when it comes to choosing a framework because only testability, debuggability and scalability really matter to me. Unfortunately, discovering if a framework is scalable only comes with practice and experience.
I started with two proof-of-concepts (POCs): one in Angular 2 and another one in React. Whether you consider one as a library and the other one as a framework doesn’t matter, the end goal is the same: build an app. It’s not a matter of what they are, but what they do. I had a huge preference for React, so I decided to move forward with it.
I start by creating a main folder for the app named TrelloClone. Then I create a server folder that will contain my Express app. For the React app, I bootstrap it with Create React App.
I use the structure below on the client and on the server so that I do not get lost between apps. Having folders with the same responsibility helps me get what I am looking for faster:
src: code to make the app work
src/config: everything related to configuration (database, URLs, application)
src/utils: utility modules that help me do specific tasks. A middleware for example
test: configuration that I only want when testing
src/static: contains images for example
index.js: entry point of the app
Setting up the Client
I use create-react-app since it automates a lot of configuration out of the box. “Everything is preconfigured and hidden so that you can focus on code", says the repo.
Here is how I structure the app:
A view/component is represented by a folder.
Components used to build that view live inside the component folder.
Routes define the different route options the user has when he/she is on the view.
Modules (ducks structure) are functionalities of my view and/or components.
Setting up the Server
Here is how I structure the app with a folder per domain represented by:
Routes based on the HTTP request
A validation middleware that tests request params
A controller that receives a request and returns a result at the end
If I have a lot of business logic, I will add a service file. I do not try to predict anything, I just adapt to my app’s evolution.
When choosing dependencies I am only concerned by what I will gain by adding them: if it doesn’t add much value, then I skip. Starting with a POC is usually safe because it helps you "fail fast".
If you work in an agile development you might know the process and you might also dislike it. The point here is that the faster you fail, the faster you iterate and the faster you produce something that works in a predictable way. It is a loop between feedback and failure until success.
Here is a list of dependencies that I always install on any React app: