Projects

Lead the backend engineering team in the design and development of the new architecture for the Botim App's messenger part. The efforts included: [1] Architecting messenger backend microservices which communicate using gRPC protocol [2] Define data models and DB schemas using MySQL. [3] Managing messenger backend sprints (spring master). [4] Writing messenger backend code in Rust using Tokio's async runtime library. [5] Leading QA process, including the design of an efficient QA process for code quality and test coverage.

Worked on a system which allows users to create and manage their Software Bill of Material (SBOM). They can add new components to the SBOM and get an overview of on their software supply chain risks by getting different kind of data and statistics related to each component individually or to the SBOM overall. I have helped the team with the database and backend design through several live work sessions. Created new Jira tickets and worked on the new Restful and GraphQL APIs which is going to help in creating new Risk Tags, update existing Risk Tags, delete existing Risk Tags, and get existing Risk Tags. Worked on, implementing the business logic which evaluates risk tags based on user-defined rules and component-related metrics stored in our data store. We used git and Bitbucket to manage source code repositories and to implement CI/CD pipelines. Technologies & tools used: Golang, PostgreSQL, Docker, Jira, Git, Bitbucket, Goland, Postman, ELK stack, TablePlus, MacOS.

I have helped the team in creating new backend Restful and GraphQL APIs to basically fetch transitive dependencies for each component from PostgreSQL datastore and implement the business logic to recursively build the tree. Another API has also been developed to expand each component to its transitive dependencies by using the first API. This has enabled new features on the UI, i.e. expand a component and “bulk expand” software list. I helped the team in the design and development of new API which is going to add new relationships between related components (directly or transitively), and that has provided users with the capability of figuring out wither their components are related. Those new features are being used by production environment. We used git and Bitbucket to manage source code repositories and to implement CI/CD pipelines. Technologies & tools used: Golang, PostgreSQL, Docker, Jira, Bitbucket, Goland, Postman, ELK stack, TablePlus, MacOS.

KaiPush is a push notification system designed for mobile devices running KaiOS, built upon the foundation of Mozilla Autopush. It underwent key modifications to enhance its capabilities: - Database Shift: Instead of AWS Dynamo DB, KaiPush employs Cassandra DB for data storage. - Authentication: The system exclusively allows KaiOS devices to subscribe to the KaiPush service. - Offline Message Restriction: A limitation on offline message storage per device per application was introduced, achieved through Redis DB. Challenges arose due to the use of Python in the original Autopush system, impacting scalability due to Python's lack of true multithreading. Efforts to accurately measure and improve its performance ensued. KaiPush comprises two primary components: 1. Connection End Point (CEP): This WebSocket and HTTP service connects directly to mobile devices via the WebSocket protocol to dispatch push notifications. 2. Router End Point (REP): An HTTP Restful server that houses APIs responsible for sending and directing push notifications to their intended devices. Initially, the throughput was limited to around 100 transactions per second (TPS). This limitation led to a thorough rewrite of the REP component in GO, replacing the original Python code. This effort resulted in a substantial 20X enhancement in TPS. Subsequently, a Rust-based solution from Mozilla was adopted. Following the same modifications as the Python server (storage, authentication, and message limitation), the CEP's performance surged by a factor of 10X. Key technologies utilized in KaiPush's development encompass: Rust, Golang, Python, HAProxy, AWS/EC2, Cassandra, Redis (including Redis scripts). Security: TLS protocol for encrypted push APIs, and VAPID to authorize message sending (e.g., only WhatsApp App server can send WhatsApp messages).

The Device Financing Program (DFP) is employed to regulate the usage of mobile phones purchased through incremental payments by users. Devices can become locked if payments are overdue, surpassing the preset grace period. One notable challenge of this initiative is ensuring security. Commands directed to mobile phones must be safeguarded against reply attacks and encrypted. The DFP backend is primarily divided into two microservices: 1. Device-Facing Microservice: Comprising Restful APIs accessible to the DFP app on KaiOS devices. These APIs handle DFP registration, push notification registration, and command reception (lock, unlock, and phone release after full payments). 2. Financier-Facing Microservice: Encompassing Restful APIs accessible to device financiers. These APIs empower financiers to manage devices and take actions post payments or completion. The key technologies employed in this project encompass Golang, Java, microservice architecture, NATS message queue, Cassandra DB, Redis DB, data encryption/decryption, data formatting, Restful APIs, and performance testing.

AMS is a service provided by KaiOS technologies to enable KaiOS mobile users protect their personal information by allowing them to remotely lock their mobile phones in case they were lost or stolen. Users also had the option to wipe out their data remotely. I worked on the backend side by participating in the design, implementation, and deployment of the service in Amazon EC2. I also participated in testing, debugging and maintaining the backend system. AMS underwent several stages of improvements, and it utilized our KaiPush system to directly deliver the commands(lock, unlock, and wipe out). My efforts included helping in the development of client-side simulation tools to be able to test the system end-to-end without having the mobile device in hand. Technologies used: Golang, Java, NATS, REST APIs, Amazon EC2, HAProxy, device testing

The DFP Tester is a functional testing tool developed in Golang. Its primary purpose is to facilitate the testing of the Device Financier Program (DFP) Backend. This tool accomplishes this by subscribing to our KaiPush service via a WebSocket connection, monitoring incoming messages, and subscribing to our DFP backend using a dedicated test account. This setup effectively emulates the behavior of the DFP client installed on a KaiOS phone. Upon receiving a push notification, it promptly relays the status to the DFP backend and retrieves any pending modem commands. The DFP Tester has proven invaluable in simplifying the testing of DFP functionality, eliminating the complexities associated with mobile client testing.