Role
Senior Backend Developer / de facto Technical Lead
Commercial Chia Farming Platform
FindChia
A real-time backend for a commercial Chia farming pool, built around asynchronous PHP, WebSockets, Protobuf, PostgreSQL and custom infrastructure.
I joined the project as a Senior Backend Developer at an early stage and led the team from a minimal working application to a public beta used by real customers.
Project Overview
Period
2021–2023
Stage
Early development to public beta
Team
Senior Backend Developer, Senior Frontend Developer, Junior Frontend Developer, with a Junior Backend Developer joining later.
Status
The service remains operational several years after the main development phase.
Starting Point
When I joined FindChia, the project already had a minimal working foundation.
The application could be run locally, and users could log in to and out of their accounts, but most of the product functionality had yet to be implemented.
Under my technical leadership, the team built the beta version almost from scratch and released it to real users.
After the main development phase was completed, the project was handed over to another developer for ongoing maintenance, while I moved to another greenfield project within the same company.
My Role
My official position was Senior Backend Developer, but in practice my responsibilities also included technical leadership and development coordination.
Architecture
- Designed the backend architecture within the technical constraints defined by the CTO
- Designed real-time communication and data contracts
- Designed internal technical solutions and backend structure
Backend Development
- Implemented nearly the entire backend
- Built the integration with the Chia pool infrastructure
- Developed statistics and data-processing logic
- Designed and implemented the localization architecture
- Built a custom asynchronous ORM
- Implemented background jobs and external integrations
Technical Leadership
- Broke requirements down into development tasks
- Assigned and coordinated work within the team
- Provided technical guidance
- Coordinated backend and frontend integration
- Kept development aligned with deadlines
Product and Client Work
- Communicated directly with the client
- Elicited and clarified requirements
- Agreed on product and technical decisions
- Prepared technical specifications
Deployment and production monitoring were outside my area of responsibility.
Architecture
React Frontend
WebSocket + Protobuf
PHP + AMPHP Backend
Internal infrastructure
PostgreSQL
Redis
Protobuf messages
RabbitMQ
External systems
REST
Chia Pool API
Scheduled REST
Exchange Rate API
FindChia was designed as an asynchronous application with predominantly real-time communication between the client and server.
Most communication between the React frontend and PHP backend took place over a persistent WebSocket connection.
Message contracts were defined using Google Protocol Buffers.
The backend was built with PHP 8.0 and AMPHP using an asynchronous execution model.
Heavy and deferred operations, such as sending emails, were processed through RabbitMQ. Queue messages also used Protobuf.
Data that did not require real-time delivery, such as language packs, was cached on both the backend and frontend.
REST was used primarily for external integrations.
Engineering Highlight 01
Real-Time Communication
Most user-facing backend communication was implemented using WebSocket and Google Protocol Buffers rather than a conventional REST API.
Protobuf defined request and response structures and provided a compact, typed format for transferring data.
The same approach was used for messages processed through RabbitMQ, giving the application a consistent model for data contracts across real-time and background communication.
REST remained the appropriate choice for third-party services, including the Chia pool API and exchange-rate providers.
Chia Pool Integration
The FindChia backend integrated with a separate REST API provided by the Chia pool infrastructure.
There was no API documentation.
To understand the available data, contracts and expected behavior, I had to investigate the API directly and read the source code of the pool itself.
Based on that research, I implemented the integration layer through which pool data became available to the rest of the application.
Engineering Highlight 02
Custom Asynchronous ORM
Off-the-shelf ORM
Additional conventions and mapping
Custom ORM
Minimal asynchronous persistence layer
I designed and implemented a small Active Record-style ORM specifically for FindChia.
Using an off-the-shelf ORM such as Doctrine, Eloquent or another general-purpose solution would have introduced more infrastructure and conventions than the project required.
The backend needed only a relatively small set of standard data operations, while many queries were highly domain-specific.
Protobuf messages already served as the primary data representation for communication within the application, so introducing a full ORM entity layer would also have required additional mapping between ORM entities and Protobuf messages.
The custom ORM provided only the operations the project actually needed:
It was designed to work directly with AMPHP and allowed database operations to be executed through yield within the application's asynchronous control flow.
The result was a small purpose-built persistence layer without a heavyweight ORM framework, unnecessary mapping or abstractions the project did not need.
Engineering Highlight 03
Data Processing and Optimization
Processing and aggregating statistics was one of the more technically demanding parts of the project.
Some values had to be calculated as part of user requests, making it important to minimize the number of operations, SQL queries and intermediate data involved.
Computationally heavy daily statistics were calculated directly in PostgreSQL wherever appropriate.
Instead of loading large datasets into PHP and processing them at the application layer, the database performed the calculations and aggregation and returned the resulting values.
Other optimization techniques used across the backend included:
Scheduled jobs were also used to retrieve external data.
For example, currency exchange rates were fetched from an external REST API once per hour.
- Batch loading of related data
- WHERE IN queries instead of sequential requests
- Calculations and aggregation directly in PostgreSQL
- Caching for data that did not require real-time updates
- RabbitMQ for operations that should not block user requests
- Compact Protobuf messages
- Persistent WebSocket communication
Engineering Highlight 04
Localization as Data Architecture
I designed a custom localization system that separated technical data from its human-readable representation.
Technical entities did not store user-facing text directly.
Instead, they stored phrase identifiers that the localization system resolved into the appropriate text for the requested language.
This kept business logic and technical data independent of the selected language.
The backend supported dynamic language packs, and the architecture was designed so that managers could eventually maintain user-facing text and translations without developer involvement.
I did not complete the corresponding administration interface before the project was handed over for maintenance.
Language packs were cached on both the backend and frontend.
Technical Entity
Phrase ID
Localization Layer
Requested Language
Localized Text
Protobuf Response
Administration UI planned, not completed before handover.
Dynamic Multilingual FAQ
Sections
title_id
FAQ records
question_id
answer_id
Unique phrase IDs
Batch-load translations
Language pack
Localized Protobuf response
Client
Translations loaded in batches — no query per FAQ item
The FAQ was a good example of the localization architecture in practice.
Its structure—sections, subsections, questions and answers—was stored separately from user-facing text.
Titles, questions and answers referenced localized phrase IDs.
Answer content was stored as Markdown, while conversion to HTML was handled by the frontend.
To retrieve an FAQ section, the backend:
As a result, the number of SQL queries did not grow proportionally with the number of FAQ entries.
Users could also open a specific question directly in its expanded state using the section and question identifiers.
- Loaded the required subsections
- Loaded all associated questions and answers in a single query
- Collected the unique phrase IDs required for the response
- Loaded the corresponding translations in a single query
- Assembled the resulting data tree in memory
- Returned only the required localized Protobuf representation
Localized Nickname Generator
- Happy Raccoon
- Wealthy Lion
- Content Otter
Another product feature I conceived and implemented was a randomized user nickname generator.
The idea was similar to the automatically generated names assigned to anonymous users in Google Docs.
The system combined a randomly selected characteristic with an animal to produce names such as:
The generator supported all application languages and accounted for language-specific grammar, including grammatical cases and word agreement where required.
It therefore did more than concatenate two translated strings.
The resulting combinations had to remain grammatically correct and natural-sounding in each supported language.
I designed both the concept and the implementation.
Result
- Early development
- Public beta
- Real users
- Maintenance handover
Under my technical leadership, a small development team took FindChia from a minimal application with working authentication to a public beta used by real customers.
During the project, we delivered:
Once the main development phase was complete, the project was handed over to another developer for ongoing maintenance.
Having completed my role on FindChia, I moved to another greenfield project within the same company.
FindChia remains operational several years after the handover.