Role: Concept, design, development and infrastructure. Year: 2020.
For a financial investment company I built the whole IT infrastructure: two management web apps, a mobile app and the services that hold them together, from idea to launch.
You are viewing this case study with the Legacy engine. To see it as it was designed, enable native rendering below.
Customers in Excel sheets
At first the company managed its customers with Excel sheets.
It commissioned me to build its whole online presence: applications, design, development and infrastructure.
From idea to launch
Designing the applications, together with the company.
The visual design.
Two management web apps, with Nuxt and Vue on the frontend and Node.js and AdonisJS on the backend.
A mobile app with Ionic, Vue and Capacitor, for Android and iOS, with its own NestJS server.
The Laravel microservices that hold it all together.
The servers and launching all of it, apps included.
A single door
The web apps and the mobile app talk to one server only, which acts as the front door: users sign in there, and every call to the other services goes through it.
A proxy checks who is calling, adds the app and server keys and, when the request carries files, stores them on S3 first and passes the service only their details. This way the apps know a single address, and every service always knows who is calling it.
Services working together
Everything goes through the core: the apps sign in there, and from there they reach the other services. IAM doesn't handle sign-in: it tells the core and the app who can go where.
The web client area and the mobile app talk only to the core: single sign-in, users, proxy.
From the core you reach the app backend, with its data; the files, that is the PDF forms; the queues, in both directions; the notifications, with news and alerts.
IAM gives roles and permissions to the core and the app backend; it doesn't handle sign-in.
The access control app talks to the notifications.
Node and Laravel on the same queue
A job starts in Node, goes through the Laravel queue and is done by an endpoint, written in the catalogue.
The core and the app backend, in Node, and the scheduler, in Laravel, put jobs in the queue: the jobs table, in MySQL, in Laravel's format.
The Laravel worker picks up the job and reads address, method and keys in the catalogue.
It calls the service's endpoint, which does the actual work.
The outcome goes to the results, with request and response saved, or to the failed jobs, which go back in the queue from the panel.
The Node servers write jobs straight into the Laravel queue, in its own format: a job created by Node is run by a Laravel microservice.
A scheduler runs the periodic jobs on time, such as the month-end calculations, calling the services with dedicated users; if something goes wrong, the job stays among the failed ones, to be retried.
All notifications go through one service: every app puts them in the queue, and it stores them with recipients and reads and sends them in-app, as push or by email.
Data is on MongoDB, shared between the services; MySQL for the queues, Postmark for emails and online contract signing.
From servers to stores
The servers, managed by me: at first the Node ones on Heroku, then everything moved to DigitalOcean droplets managed with Laravel Forge.
The databases on MongoDB Atlas and the backups on Amazon S3.
The mobile app published on the App Store and Google Play.
Like an online bank
Every customer with their own profile and private area.
Customers operating on their own, as in online banking.