Gateway Services
In today applications, it is sometimes necessary to access external services (like external databases, object storage, or caches). The standard approach requires adding service-specific SDKs and dependencies to your application, which increases complexity, package size, and tight coupling.
DotHRB provides Gateway Services to eliminate this complexity. Our internal HttpClient handles all external communication by talking to dedicated, protocol-aware Gateway services via a simple HTTP/REST interface. This keeps your DotHRB application clean, lightweight, and completely decoupled from the underlying service protocols.
This component is in an incubation phase. There are currently no guarantees of further development or a final release. Continued progress is strictly contingent on significant community interest and feedback.
🛠️ The Gateway-per-Service Pattern
We employ a "Gateway per Service" pattern to provide uniform, simplified access to key infrastructure components. The DotHRB application only needs to know the Gateway's HTTP endpoint.
| Gateway Service | Backend Service | Interface Exposed | Primary Benefit |
|---|---|---|---|
| S3 Gateway | Amazon S3 (or S3-compatible) | REST API (HTTP) | Simplified object storage access, authorization/policy enforcement. |
| SQL Gateway | SQL Server/Oracle/etc. | REST API (HTTP) | No SQL Driver needed in the DotHRB application. Connection pooling and query sanitization. |
| Redis Gateway | Redis/Elastic Cache | REST API (HTTP) | No Redis Client needed in the DotHRB application. Caching layer abstraction. |
🌐 Architecture: DotHRB with Gateway Services
This diagram illustrates how the DotHRB Application connects to external services only through its standard HttpClient, relying on the dedicated Gateway services to manage the native protocol connections.