Author: Dimitar Dishev
A couple of months ago, we were at the final step of teaming up with Uncoated.
The company is a danish-based digital marketing agency, helping brands drive business and customer relationships. We were looking at building a SaaS solution from the ground up. This digital product was to be aiding marketing specialists from McDonald’s in various locations worldwide, giving them the opportunity to create gamification campaigns and thus drive more business. We were looking at a blank page and we had the freedom to choose whatever appropriate technologies we wanted and felt comfortable with.
Fast forward to today,
the task we have at hand is to build an API that will be consumed mostly by 2 front-end applications. The API has to be prepared for a huge amount of requests and will be processing a lot of user interaction event and building insights reports based on them.
The platform will be serving the execution of key marketing activities — the creation of campaigns, based on gamification, which will be gathering many users all at once. Our prognosis is that we will have at least 100 000 active users per day during a running campaign. This may go up to 500 000 or even more per day, which makes a good amount of requests while the users are actively playing. Of course, the platform will have common functionalities like authentication, roles and permissions, real-time, mailing, CRUD operations on different resources, etc.
Each team at Lab08 is dedicated to one particular product.
As a Tech Lead of this team, I had the opportunity to research and propose the tech stack and approach for building this solution. Considering what technologies to use, we sat down with the team and laid down our options. What tools do we have on the table for executing this task?
- As a company, Lab08 has a lot of experience with PHP 7.x and lately with 8, together with Laravel from version 5 to the latest one (8). Back in the day, we have also had our close interaction with Symfony, Zend, and CakePHP. We have used and still use some of those technologies for building various web solutions.
- Most of the senior developers/tech leads in the company have a strongly typed technology background — Java, tools like GWT (deprecated), TypeScript.
- We do have a lot of experience with AWS as a cloud services provider
- And almost all of the tech guys in the team have experience with JavaScript in all kind of forms — Vanilla JS, React with Redux, Angular, Vue.js with Vuex and Node.js with Express
Both PHP (with Laravel) and Node.js (with NestJS) will do the job, but there are a few things we took into account that helped us make our decision:
- PHP is great, especially with the latest releases, it offers great performance and a lot of improvements, but still, Node.js shows better performance thanks to the async approach
- The well-known advantage of using JavaScript for the back end and front end also gives us a lot more flexibility in the development team — this means that more developers can contribute to both the front and back end and collaborate more on different components of the product we will be building
- NestJS enforces good DDD architecture and separation of concerns, so one can invite an Angular Front-End developer to work on the back end and he/she would manage with ease
- Node.js is better when it comes to building a JSON API — it is not messing up with HTML (separation of concerns), while with PHP you may have the temptation to serve HTML right from the monolith
- Node.js and especially the NestJS communities feel more conversant. In the PHP world, it takes more time to filter out the noise, there is a lot of information for every potential problem you have in PHP, but most of the solutions are far from the best
- With the rapidly growing ecosystem around JavaScript, which has its pros and cons, comes NestJS which gives the promise of LTS and relies on proven architecture and principles
- A lot of popular programming languages like Python, Java, C and Ruby can be compiled to JavaScript — see here
- npm/yarn have a large pool of dependencies and they require more wise picking and double-checking when it comes to installing yet another dependency in the project. Personally, I don’t think the composer world is much different. you always have to think twice and verify when you invite someone else to contribute to the code inside a project
- TypeScript is way better than PHP’s native types of “warning” support. Of course, it comes with a learning curve for people who have never used a strongly typed language and it has drawbacks when you want to use some npm dependency that doesn’t have TypeScript support, but the truth is that almost all of the popular packages already have it
In the end, based on all of the above, we chose Node.js and so far everything looks promising in terms of performance, development speed, unit testing. We will be happy to share another update after a couple of months, where we will cover the biggest challenges we have faced and essentially provide an answer to the question “Would it be better if we were doing this with PHP?”
Dimitar is a Tech Lead for one of the teams at Lab08. He has 7 years of professional experience in product and outsourcing companies. He has domain experience in areas like marketing, social networks and e-commerce. Dimitar speaks PHP, NodeJS and is a certified Java 7 specialist. In his work, he used databases such as MySQL, PostgreSQL, MongoDB, as well as the following cloud solutions: AWS, Google Cloud, DigitalOcean. Mitko has experience in the design and architecture of systems and databases. He will be one of the main contributors to our future tech stories. Stay tuned!
Be sure to follow us on social media to receive updates about other similar content!
Make sure you check out Lab08’s blog, where you will find tech and business articles.
