← All work

Webloo / Software architecture & application development

Application architecture and real-time systems

Leading full-stack application work across APIs, PostgreSQL, GraphQL, asynchronous processing, notifications and geo-search.

Software Engineering Lead and DevOps Architect

ClientsAPIs & eventsServicesData & search
Illustrative engineering scope; not a client topology.

Context

My application work at Webloo covered more than a frontend or a backend in isolation. I led development involving React, Node.js, TypeScript, PostgreSQL and GraphQL, alongside real-time behavior, notification systems, message queues and integrations.

The work connected product behavior with the architecture underneath it: how an interface requests information, where that information lives, which operations can happen asynchronously, and how the system exposes useful information when something fails.

My responsibility

As Software Engineering Lead and DevOps Architect, I led application design and implementation, worked on modular structures and reusable components, and coordinated with cross-functional teams. My broader Webloo responsibilities included backend services, REST and GraphQL APIs, payment integrations and Elasticsearch-based geo-search.

I also worked on project documentation, proofs of concept and technical planning. Explaining an approach and its implications was part of the implementation work.

Engineering approach

The application stack combined React and TypeScript at the interface with Node.js services and PostgreSQL-backed data. REST and GraphQL provided different interfaces for connecting application capabilities.

My work also included asynchronous processing through message queues, notification systems and real-time applications. These introduce a second kind of interaction alongside a direct API call: work can continue after the initial request, and updates have to reach the people or services that depend on them.

Elasticsearch was part of the geo-search work. Search introduces its own representation of information and its own operational concerns alongside the application’s primary data and APIs.

Complexity and trade-offs

Modularity is useful when it gives a team clear responsibilities and a practical way to change a system. It also requires attention to interfaces, shared data and the dependencies between components.

Asynchronous work changes how completion and failure are represented. A request being accepted is different from the work being finished. Notifications and real-time updates need to reflect those states clearly, while logs and monitoring need to make the path through the system understandable.

Search and transactional data also have different jobs. Keeping those responsibilities clear helps frame questions about freshness, consistency and the experience presented to a user.

What this work brought together

This work connected full-stack development with distributed application concerns: APIs, data, background processing, notifications, search and monitoring. My role included both the technical implementation and the planning and collaboration needed to move that work forward.

Sources & further reading

← Back to the work archiveWhat I’m exploring now →