Modern applications rarely need only a user interface and a database. As a product grows, it usually needs authentication, controlled data access, server-side operations, realtime updates, background processing and caching.
WBert is designed to provide that common backend layer. Web, desktop, mobile, Unity and backend applications can use the same platform instead of rebuilding the same infrastructure for every client.
What WBert is designed to solve
Infrastructure grows quickly around an application. Users need authentication and verification, clients need controlled access to data, business operations need to run on the server, and applications may need realtime updates, background jobs or caching.
These capabilities are important, but they are usually not the product itself. WBert centralizes them so application code can focus on the workflow and user experience.
- Authentication and authorization
- API access to backend operations
- PostgreSQL data and database functions
- Realtime database change events
- Direct or queued application processes
- Queue infrastructure with WBert Internal Queue or RabbitMQ
- Cache infrastructure with WBert Internal Cache or Redis
- Admin and developer tooling for endpoints, schemas and integrations
One backend for different applications
WBert is not tied to a single frontend technology. A React or Angular application, a C# desktop tool, a mobile application, a Unity client or another backend service can communicate with the same backend while keeping its own presentation and client-side logic.
The important boundary is that clients do not need direct PostgreSQL credentials or direct access to infrastructure such as Redis or RabbitMQ. They communicate with WBert, and the backend remains responsible for shared and authoritative operations.
Authentication, APIs and PostgreSQL
Account management is one of the first shared concerns in many applications. WBert provides registration, email verification, login, role and permission capabilities that can be reused across clients.
Database access follows the same principle. Instead of giving each client direct PostgreSQL access, WBert provides a controlled backend surface for CRUD operations and PostgreSQL functions.
PostgreSQL functions through the backend
Some business operations should be executed as one server-side operation rather than as several independent client writes. WBert can execute saved PostgreSQL functions through db.ExecuteFunction, with function permissions checked by the backend for normal user-token calls.
View example request
{
"endpoint": "db.ExecuteFunction",
"parameters": {
"connector": "main",
"functionName": "main.fn_example",
"values": {
"input_text": "hello"
}
}
}Built-in tooling for faster development
WBert is not only a backend runtime boundary. The platform also includes developer-facing tools that help teams discover configured endpoints, understand the database structure and accelerate integration work without adding a large amount of extra documentation to every project.
The blocks below stay collapsed by default so the article remains concise, but they show the kind of platform tooling that can speed up day-to-day backend work.
View: API endpoint explorer
The API Endpoints section helps developers browse configured endpoints, inspect their required authentication mode and review example request parameters. This gives client-side and backend developers a clearer contract for how the application should talk to WBert.
View: AI helper for endpoint integration
WBert can also generate an AI-oriented helper text based on the configured endpoints visible in the application. This gives a developer a structured prompt that can be pasted into an AI chat to generate starter JavaScript or TypeScript integration code more quickly, while keeping the output aligned with the currently configured API surface.
View: database schema visualizer
For applications with a growing PostgreSQL model, the schema visualizer provides a graphical way to inspect tables and their relationships. This helps developers orient themselves more quickly when working on data models, server-side functions or application flows that depend on multiple entities.
Realtime database changes
Polling is useful as a fallback, but it is not always the best primary mechanism when data can change independently of the current user. WBert can publish configured database changes through its realtime layer so subscribed applications can react when relevant rows change.
View realtime subscription
client.on("db_changes", {
event: "*",
connector: "main",
schema: "main",
table: "orders"
}, handler);The client can then decide whether to update a card, refresh a list or fetch the changed record. This keeps presentation logic in the application while WBert provides the notification channel.
Background processing, queueing and caching
Not every operation belongs inside the HTTP request that triggered it. WBert processes can execute application work directly or through background processing. The queue layer can use WBert Internal Queue or RabbitMQ, allowing the deployment to change infrastructure without exposing that choice to client applications.
The same separation applies to caching. WBert can use its Internal Cache or Redis while clients continue to work through the backend.
Why a shared backend boundary matters
The value becomes clearer when a product has several clients. An Angular administration interface, a C# desktop tool, a mobile application and a background service can all need the same identity, data and business rules.
Without a common boundary, those applications can gradually duplicate authentication flows, data-access rules and backend logic. With WBert, each client remains specialized while shared responsibilities stay centralized.
Clients own presentation and interaction. The backend owns shared identity, authorization, data access and authoritative operations.
Where WBert goes from here
This article is intentionally an introduction. The next articles will focus on specific engineering problems and show how the relevant WBert capabilities can be used in practical architectures.
A first example is Saga Pattern in Microservices: A Practical .NET Example, which uses an order workflow to examine distributed failure, compensating actions, queued processing and realtime status updates.