ERP system for a seals manufacturer

We met in person to discuss Megabelt's needs and how we can help. Together we arrived at the conclusion that the custom ERP system would cover the client's use cases the best. We started preparing the software specification as a way to communicate about the project with the client using a common language (as we obviously knew nothing about manufacturing seals).

This was going to be an internal system so custom design was not a priority as long as it would provide a great user experience. That's why we've chosen Material UI – it allows us to be able to deliver fast by using existing components library and also end-users have usually used an application with Material UI before so onboarding would be much smoother.

The majority of the defined use cases consisted of CRUD operations on the database, therefore we decided to try out front-end framework react-admin that focuses on B2B applications and is built on top of React.js, Material UI, Redux and React Router. Later we found out that yes, it was great for building standard CRUD screens, but rather struggled when we needed to create more specific functionality and screens. From this experience, we've learned that it would be much better to just learn and get inspiration from react-admin instead of using it as a cornerstone of the whole application.

For the back-end, we've also tried a new technology and replaced Express with Koa.js, which is a new framework but designed by the same people as the most popular Express. This allowed us to simplify our code thanks to properly cascading middleware and use less hacky code. Postgres was chosen as it is our database of choice together with query builder library knex. On top of knex, we used Objection.js which is an ORM library but is very flexible and could almost be described as a relational extension to knex. In contrast to other ORMs, it doesn't try to be smart all the time but allows us to keep it simple in simple scenarios and effortlessly dial back to lower-level API for complex scenarios.

For authorization, we've chosen role-based authorization as the client needed to be able to customize what roles can have what permissions on his own while the app would be in production. Together we specified what permissions would be supported in the system as individual capabilities and created an interface for him to assign permissions to custom roles and then assign roles to individual users.

To streamline the production as much as possible we implemented automatic email notifications to let the next people in the production line know the previous phase is completed as soon as possible. We also added a kanban board interface to give managers a perfect overview of all ongoing orders and the states they are in. Last but not least we parameterized all calculations and created an interface for the company's director to change those variables at will.

A crucial function for our client was the ability to export and import records from/to the database. We implemented it in the form of CSV exports and imports to allow the client to make bulk changes to the whole database while allowing him to make additional calculations in Excel and experiment with results aiming to set every number perfectly and deliver the best service possible to their customers. This has proven to be one of the biggest challenges as Excel uses formatted values in saved data instead of normalized ones and so we had to account for different formatting options that could occur. For example numbers in English are typically formatted as 1,234.56 while in Slovak it's 1 234,56. At the same time, the system had to be reliable even with big imports of the entire warehouse.

We were developing the system for only one part of the client's production - machined seals, but with plans to extend it in the future. That's why automated tests were included in the delivered solutions, increasing our confidence in the reliability and stability of the system allowing us to extend it in the future without worries about breaking existing parts. We've chosen to write only integration tests as they provide the best bang for the buck in our opinion.

The whole time we were using continuous integration with the help of GitLab's CI/CD running code style linting using the ESLint and integration test in the hands of Mocha test runner. Each merge request went through automated tests and linting to catch most errors before rigorous code review. We deployed the staging environment on our server to allow the customer to test new features as we were adding them. Continuous delivery to both staging and production environments was a breeze using GitLab's integrated Docker registry. On every commit to the master branch, we build a new Docker image and deploy it to the staging environment. In a similar manner, tagged commits get built and deployed to the production environment.