Solving Flexibility Issues with SaaS Approach
About the product
Routyx is a product that serves as an operational software for the transportation and logistics industry.
When first introduced, Routyx was servicing only part of the business processes, such as route planning, GPS tracking, route invoicing and basic reporting. However, as we got more deeply into the industry, talking with representatives from different companies, the need for a more inclusive, the wider system was soon identified.
This initiated for Routyx to take a bit different route and adjust the business goals, to be able to cover the market gap. Today, Routyx is an integrated TMS solution that works closely with industry leaders from the region in order to deliver the right solutions for the challenges within the transportation industries.
As the list of clients was growing, and as we were getting more and more know-how from our partners we realized that we work within an industry that runs on more exceptions, than rules. This means that on a daily basis, operators in different levels and different departments within a company, are constantly dealing with some kind of crisis management.
For Routyx, this means that our software needed to be flexible enough, so that each transportation company that would use it, can adapt it to fit their specific transport-related processes, and also to the way they deal with each of their customers. Meanwhile, the client list was growing, and with that, the number of users and user types within the system, which increased the necessity for visibility of each activity performed with the software.
To overcome the challenge above Routyx needed to be developed as a modular SaaS solution, enabling different clients to use only the parts of the system that they need. This creates a specific issue with scalability. If some modules are more heavily used then others, we have to scale up the whole system.
That’s where the modular architecture comes in, each part of the system is built as an independent API, and the front end is written as a separate app in Angular. The good thing about this approach is that the Angular app doesn’t care where the data is coming from, so when needed, we can scale only parts of the system, or replace them with a faster and more optimal solution.
The whole system is quite complex, it uses one of the best PHP frameworks out there, Laravel, and MySQL DB for the API, Angular for the front end, Node.js and MongoDB for collecting the tracker data, and it’s all hosted on Amazon AWS Cloud.
The modular/microservices approach has a lot of other advantages in complex systems. It is more flexible, different services can be built in different technologies, which gives us the possibility to assign different teams to develop different modules as separate products. This gives a lot more room for improvement and innovation.
It is also more reliable because if one part of the system fails, the entire application doesn’t go down. Development speed is also a key factor since the volume of code is reduced – it’s easier to understand and modify it.