A discussion of how a team of web developers went about designing a Kanban board app, from planning to coding to automated testing, using React and MongoDB.
QArea’s expert web development team had quite a journey in front of them. Let’s start with talking about why we did something instead of how we did it. This mindset is an essential element of clever business-oriented development planning, because it happens to save a lot of time and costs in the long run, because we can afford ourselves to avoid any unnecessary work.
Here’s why we chose React for the project. First and foremost, React is not a framework, but rather a library. Yes, some may consider it a downside, but we do not. At least for this particular project we don’ t.
A library topped our odds for a Trello-like app because it offers a declarative method for defining UI components.
That noted, React allows for absolutely separate front-end and back-end development. Andy was particularly picky when it came to the design of his app, hence we needed to make sure tons of upcoming changes wouldn’t affect the entire system. React’s presentation layer did just fine.
The level of freedom and flexibility we required for this project was also complimented by the fact that we chose a library over a framework. Frameworks have rules that lead to lock-ins, while libraries have a philosophy that you can always bend to your will or simply ignore if need be.
More on that notice – we’ ve paired React with Redux. Why? Because Redux is simply amazing when it comes to managing data-state as well as UI-State JS apps.
Redux allowed us to store our entire app state in a single place, or a “store, ” if you will. This way neither of the app’s components had the need to dispatch state changes directly to other components. This is, in fact, an important element of the application, because we’ ve managed to prevent chaos between components in the application.
Now I will say components once again for you to entirely get lost. And once more, just for the bells and whistles: components, components.
Obviously, text isn’ t the best way to highlight how helpful Redux was, really. So here’s an image. Hopefully, it will make clarify my thoughts fairly well.
All in all, Redux made the data flow easier.
Then there’s Node.js. We were, after all, making an event-driven application. Node.js allowed us to create a main loop that’s on a constant lookout for all kinds of events happening in the system. The loop is there to trigger a call-back function once an event is noticed.
The non-blocking I/O API was also one of the major benefits, if not the most important one for Strategic Quadrants, given the application will be under constant, massive use. The API optimized the app’s scalability and it’s throughput.
Node.js is, well, JavaScript, meaning we could use the same good old language on both the front-end and back-end of the app without any second thoughts or additional considerations. This allowed us to save dozens of hours on development because we were empowered to build features, not patches or fixes.
And, finally, there’s MongoDB. Its benefits are well-known and yet I would still like to highlight why it was the best choice for a Trello-inspired application. Our team was gaining clarity in the structure of any given object. There was no need for complex joints or even schemes – in MongoDB, a single database is a collection of different documents.
Now that we knew what we needed the time was right to show results. And is there a better way to check if we did well then to compare what was brought to the table by our engineers with relevant benchmarks everyone looking to find web developers for a startup should be aware of?
According to Ruby Garage, the schedule for a project on that big of a scale will require a team of six (one designer, two front-end developers, two back-end developers, and a single QA engineer) and it will take anywhere from 1,152 to 1,278 hours.
We released the product in as little as 763.8 hours. And it only took three people from our side – one developer, one designer, and a Project Manager.
How’ d that work?
For starters, we were smart about tool choices. The blend of React, Redux, Node.js, and MongoDB worked out seamlessly. The architecture allowed us to create great designs separately from the app’s back-end, database interactions were smart and consistent, and, lastly, we avoided complex joints or hard coding.
We had the most fitting tech on our side, and we also had a little secret – an ace up our sleeve. That ace was a system we developed over 17 years in the business of outsourcing.
Care to learn more about it? Sure you do!
Lean a bit closer, because we are about to show you how to make this
Into this:
The procedure that allows us to prevent errors from even happening before wasting any time on fixes is what we like to call the Continuous Success methodology. We will only describe it briefly here.
So how does Continuous Success work for our clients? We start the process with the strict analysis of technical requirements and come up with exceptional architecture choices as well as the most fitting technologies. All of that is already covered above.
The next stage of an endless cycle is constant control. We use automated tests on every single line of code before submitting it to the repository. We enhance automated tests with a static code analysis tool we’ ve made from scratch for the sake of more transparent outsourced projects. The tool operates according to SQALE rating standards.
This way all of the code our developers produce is checked not once, but twice with an automated test. Not only do we test its functionality, but we test the complexity of syntaxis, hard coding flaws, and much more. It’s even safe for us to state that the code we deliver is mostly bug-free.
Our clients are involved in every stage of development. They clearly see the progress as well as analytical statistics based on issue probability and can (if need be) guide us to safer business decisions.
No, seriously, that’s it. That’s all you need to know to make your own Kanban canvas app.
