upd: makefile, readme, and license updated
This commit is contained in:
parent
fa7ce72f98
commit
3a400e94ee
GPG Key ID:
19C3D328D8C8F65F
16
.gitignore
vendored
16
.gitignore
vendored
@ -0,0 +1,16 @@
|
||||
# Software
|
||||
.obrimbaseapi
|
||||
|
||||
# Environment
|
||||
.env
|
||||
.env/
|
||||
|
||||
# Temporary
|
||||
.tmp
|
||||
*.tmp
|
||||
.tmp/
|
||||
|
||||
# Backup
|
||||
.bkp
|
||||
*.bkp
|
||||
.bkp/
|
||||
@ -0,0 +1,9 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2026 Startupore
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
282
Makefile
282
Makefile
@ -0,0 +1,282 @@
|
||||
# =========================================================
|
||||
# Variable
|
||||
# =========================================================
|
||||
|
||||
# Framework
|
||||
# Identity and metadata of framework. Human-readable name, machine-readable names(lower and upper), and semantic version.
|
||||
FRAMEWORK_REGULAR=Framework Regular
|
||||
FRAMEWORK_LOWER=frameworklower
|
||||
FRAMEWORK_UPPER=FRAMEWORKUPPER
|
||||
FRAMEWORK_VERSION=0.0.0
|
||||
|
||||
# Software
|
||||
# Identity and metadata of software. Human-readable name, machine-readable names(lower and upper), and semantic version.
|
||||
SOFTWARE_REGULAR=Software Regular
|
||||
SOFTWARE_LOWER=softwarelower
|
||||
SOFTWARE_UPPER=SOFTWAREUPPER
|
||||
SOFTWARE_VERSION=0.0.0
|
||||
|
||||
# Go Module
|
||||
# App module and import path used by go.mod and source imports. Valid Go module path.
|
||||
GO_MODULE=go/module
|
||||
|
||||
# Directory
|
||||
# Locations used by build and management commands. Relative or absolute paths.
|
||||
SOURCE_DIR=./run/main
|
||||
RELEASE_DIR=./release
|
||||
FRAMEWORK_METADATA_DIR=./data/framework/metadata
|
||||
SOFTWARE_METADATA_DIR=./data/software/metadata
|
||||
|
||||
# File
|
||||
# Metadata file names without extension. File name only.
|
||||
FRAMEWORK_METADATA_FLE=resource
|
||||
SOFTWARE_METADATA_FLE=resource
|
||||
|
||||
# Derived Path
|
||||
# Automatically generated from directory and file variables. Do not edit.
|
||||
FRAMEWORK_METADATA_PATH=$(FRAMEWORK_METADATA_DIR)/$(FRAMEWORK_METADATA_FLE)
|
||||
SOFTWARE_METADATA_PATH=$(SOFTWARE_METADATA_DIR)/$(SOFTWARE_METADATA_FLE)
|
||||
|
||||
# Target File Type
|
||||
# File types scanned by update commands. Valid find expression.
|
||||
TARGET_FILE_TYPE=\
|
||||
-name "*.go" \
|
||||
-o -name "*.json" \
|
||||
-o -name "*.yaml" \
|
||||
-o -name "*.yml"
|
||||
|
||||
# Go Module Placeholder
|
||||
# Replacement rules applied by upd-go-mod. Valid sed replacement expressions.
|
||||
GO_MODULE_REPLACEMENT=\
|
||||
-e 's|gomodule|$(GO_MODULE)|g' \
|
||||
-e 's|go/module|$(GO_MODULE)|g' \
|
||||
-e 's|go-module|$(GO_MODULE)|g' \
|
||||
-e 's|go_module|$(GO_MODULE)|g'
|
||||
|
||||
# =========================================================
|
||||
# Command
|
||||
# =========================================================
|
||||
|
||||
# PHONY Target
|
||||
.PHONY: \
|
||||
help \
|
||||
go-ini \
|
||||
upd-go-mod \
|
||||
upd-fw-imd \
|
||||
upd-sw-imd \
|
||||
go-tid \
|
||||
go-stp \
|
||||
pre-rel \
|
||||
go-bld \
|
||||
go-bld-lin \
|
||||
go-bld-win \
|
||||
go-bld-mac \
|
||||
bld-lin-amd \
|
||||
bld-lin-arm \
|
||||
bld-win-amd \
|
||||
bld-win-arm \
|
||||
bld-mac-amd \
|
||||
bld-mac-arm
|
||||
|
||||
# Default Command
|
||||
.DEFAULT_GOAL := help
|
||||
|
||||
# =========================================================
|
||||
# Help
|
||||
# =========================================================
|
||||
|
||||
help:
|
||||
@echo ""
|
||||
@echo "Available Command:"
|
||||
@echo ""
|
||||
@echo " make go-stp Initialize Go module and tidy dependencies"
|
||||
@echo ""
|
||||
@echo " make upd-go-mod Update Go module placeholders"
|
||||
@echo " make upd-fw-imd Update framework metadata"
|
||||
@echo " make upd-sw-imd Update software metadata"
|
||||
@echo ""
|
||||
@echo " make go-bld Build all platform binaries"
|
||||
@echo " make go-bld-lin Build all Linux binaries"
|
||||
@echo " make go-bld-win Build all Windows binaries"
|
||||
@echo " make go-bld-mac Build all macOS binaries"
|
||||
@echo ""
|
||||
@echo " make bld-lin-amd Build Linux AMD64 binary"
|
||||
@echo " make bld-lin-arm Build Linux ARM64 binary"
|
||||
@echo ""
|
||||
@echo " make bld-win-amd Build Windows AMD64 binary"
|
||||
@echo " make bld-win-arm Build Windows ARM64 binary"
|
||||
@echo ""
|
||||
@echo " make bld-mac-amd Build macOS AMD64 binary"
|
||||
@echo " make bld-mac-arm Build macOS ARM64 binary"
|
||||
@echo ""
|
||||
|
||||
# =========================================================
|
||||
# Initialize
|
||||
# =========================================================
|
||||
|
||||
go-ini:
|
||||
@test -f go.mod || go mod init $(GO_MODULE)
|
||||
|
||||
go-tid:
|
||||
go mod tidy
|
||||
|
||||
go-stp: \
|
||||
go-ini \
|
||||
go-tid
|
||||
|
||||
# =========================================================
|
||||
# Update
|
||||
# =========================================================
|
||||
|
||||
upd-go-mod:
|
||||
|
||||
@find . -type f \
|
||||
\( $(TARGET_FILE_TYPE) \) \
|
||||
-exec sed -i \
|
||||
$(GO_MODULE_REPLACEMENT) \
|
||||
{} +
|
||||
|
||||
@if [ -f go.mod ]; then \
|
||||
sed -i \
|
||||
$(GO_MODULE_REPLACEMENT) \
|
||||
go.mod; \
|
||||
fi
|
||||
|
||||
@go mod tidy
|
||||
|
||||
@echo "Go Module Updated!"
|
||||
|
||||
upd-fw-imd:
|
||||
|
||||
@jq \
|
||||
--arg framework_regular "$(FRAMEWORK_REGULAR)" \
|
||||
--arg framework_lower "$(FRAMEWORK_LOWER)" \
|
||||
--arg framework_upper "$(FRAMEWORK_UPPER)" \
|
||||
--arg framework_version "$(FRAMEWORK_VERSION)" \
|
||||
'.framework.regular=$$framework_regular|.framework.lower=$$framework_lower|.framework.upper=$$framework_upper|.framework.version=$$framework_version' \
|
||||
$(FRAMEWORK_METADATA_PATH).json \
|
||||
> $(FRAMEWORK_METADATA_PATH).json.tmp
|
||||
|
||||
@mv $(FRAMEWORK_METADATA_PATH).json.tmp $(FRAMEWORK_METADATA_PATH).json
|
||||
|
||||
@echo "Framework Metadata Updated!"
|
||||
|
||||
upd-sw-imd:
|
||||
|
||||
@jq \
|
||||
--arg software_regular "$(SOFTWARE_REGULAR)" \
|
||||
--arg software_lower "$(SOFTWARE_LOWER)" \
|
||||
--arg software_upper "$(SOFTWARE_UPPER)" \
|
||||
--arg software_version "$(SOFTWARE_VERSION)" \
|
||||
'.software.regular=$$software_regular|.software.lower=$$software_lower|.software.upper=$$software_upper|.software.version=$$software_version' \
|
||||
$(SOFTWARE_METADATA_PATH).json \
|
||||
> $(SOFTWARE_METADATA_PATH).json.tmp
|
||||
|
||||
@mv $(SOFTWARE_METADATA_PATH).json.tmp $(SOFTWARE_METADATA_PATH).json
|
||||
|
||||
@echo "Software Metadata Updated!"
|
||||
|
||||
# =========================================================
|
||||
# Release
|
||||
# =========================================================
|
||||
|
||||
pre-rel:
|
||||
@test -n "$(RELEASE_DIR)"
|
||||
@mkdir -p "$(RELEASE_DIR)"
|
||||
@find "$(RELEASE_DIR)" -mindepth 1 -delete
|
||||
|
||||
# =========================================================
|
||||
# Build Group
|
||||
# =========================================================
|
||||
|
||||
go-bld: \
|
||||
pre-rel \
|
||||
go-tid \
|
||||
bld-lin-amd \
|
||||
bld-lin-arm \
|
||||
bld-win-amd \
|
||||
bld-win-arm \
|
||||
bld-mac-amd \
|
||||
bld-mac-arm
|
||||
|
||||
go-bld-lin: \
|
||||
pre-rel \
|
||||
go-tid \
|
||||
bld-lin-amd \
|
||||
bld-lin-arm
|
||||
|
||||
go-bld-win: \
|
||||
pre-rel \
|
||||
go-tid \
|
||||
bld-win-amd \
|
||||
bld-win-arm
|
||||
|
||||
go-bld-mac: \
|
||||
pre-rel \
|
||||
go-tid \
|
||||
bld-mac-amd \
|
||||
bld-mac-arm
|
||||
|
||||
# =========================================================
|
||||
# Build Target
|
||||
# =========================================================
|
||||
|
||||
# Linux AMD64
|
||||
bld-lin-amd:
|
||||
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
|
||||
go build \
|
||||
-trimpath \
|
||||
-buildvcs=false \
|
||||
-ldflags="-s -w" \
|
||||
-o $(RELEASE_DIR)/$(SOFTWARE_LOWER)-v$(SOFTWARE_VERSION)-linux-amd64 \
|
||||
$(SOURCE_DIR)
|
||||
|
||||
# Linux ARM64
|
||||
bld-lin-arm:
|
||||
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 \
|
||||
go build \
|
||||
-trimpath \
|
||||
-buildvcs=false \
|
||||
-ldflags="-s -w" \
|
||||
-o $(RELEASE_DIR)/$(SOFTWARE_LOWER)-v$(SOFTWARE_VERSION)-linux-arm64 \
|
||||
$(SOURCE_DIR)
|
||||
|
||||
# Windows AMD64
|
||||
bld-win-amd:
|
||||
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 \
|
||||
go build \
|
||||
-trimpath \
|
||||
-buildvcs=false \
|
||||
-ldflags="-s -w" \
|
||||
-o $(RELEASE_DIR)/$(SOFTWARE_LOWER)-v$(SOFTWARE_VERSION)-windows-amd64.exe \
|
||||
$(SOURCE_DIR)
|
||||
|
||||
# Windows ARM64
|
||||
bld-win-arm:
|
||||
CGO_ENABLED=0 GOOS=windows GOARCH=arm64 \
|
||||
go build \
|
||||
-trimpath \
|
||||
-buildvcs=false \
|
||||
-ldflags="-s -w" \
|
||||
-o $(RELEASE_DIR)/$(SOFTWARE_LOWER)-v$(SOFTWARE_VERSION)-windows-arm64.exe \
|
||||
$(SOURCE_DIR)
|
||||
|
||||
# macOS AMD64
|
||||
bld-mac-amd:
|
||||
CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 \
|
||||
go build \
|
||||
-trimpath \
|
||||
-buildvcs=false \
|
||||
-ldflags="-s -w" \
|
||||
-o $(RELEASE_DIR)/$(SOFTWARE_LOWER)-v$(SOFTWARE_VERSION)-macos-amd64 \
|
||||
$(SOURCE_DIR)
|
||||
|
||||
# macOS ARM64
|
||||
bld-mac-arm:
|
||||
CGO_ENABLED=0 GOOS=darwin GOARCH=arm64 \
|
||||
go build \
|
||||
-trimpath \
|
||||
-buildvcs=false \
|
||||
-ldflags="-s -w" \
|
||||
-o $(RELEASE_DIR)/$(SOFTWARE_LOWER)-v$(SOFTWARE_VERSION)-macos-arm64 \
|
||||
$(SOURCE_DIR)
|
||||
563
README.md
563
README.md
@ -0,0 +1,563 @@
|
||||
# ObrimbaseAPI
|
||||
|
||||
## Description
|
||||
|
||||
ObrimbaseAPI is a layered API application framework designed to provide a structured foundation for building maintainable, scalable, and extensible web services.
|
||||
|
||||
The framework separates framework capabilities, application capabilities, resource management, request processing, policy enforcement, and runtime execution into clearly defined architectural layers. It provides standardized request handling, response generation, execution pipelines, reusable utility services, and runtime orchestration while maintaining strict ownership boundaries between framework and application components.
|
||||
|
||||
The framework supports:
|
||||
|
||||
- API request routing
|
||||
- Request processing
|
||||
- Response generation
|
||||
- Policy-driven execution
|
||||
- Authentication and authorization pipelines
|
||||
- Rate limiting and validation policies
|
||||
- Runtime lifecycle management
|
||||
- Reusable infrastructure services
|
||||
|
||||
The architecture is organized into four primary layers:
|
||||
|
||||
- **Data** — Framework and application resources.
|
||||
- **Essential** — Reusable framework capabilities and infrastructure.
|
||||
- **Operational** — Application-specific business capabilities and policies.
|
||||
- **Run** — Runtime initialization, execution, and request processing.
|
||||
|
||||
This separation enables developers to focus on application behavior while relying on a consistent framework foundation for API processing, security, policy enforcement, utility services, and runtime coordination.
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
ObrimbaseAPI exists to provide a consistent, maintainable, and extensible architecture for building API-driven applications while establishing clear boundaries between framework responsibilities and application responsibilities.
|
||||
|
||||
### Objectives
|
||||
|
||||
- Establish clear separation of concerns.
|
||||
- Standardize API request and response processing.
|
||||
- Distinguish framework-owned and application-owned resources.
|
||||
- Provide reusable infrastructure and utility capabilities.
|
||||
- Centralize policy enforcement and access control.
|
||||
- Simplify application development through a structured architecture.
|
||||
- Improve maintainability and scalability.
|
||||
- Enable controlled application extensibility.
|
||||
- Protect internal framework implementation details.
|
||||
- Encourage consistent API design and execution patterns.
|
||||
|
||||
### Design Principles
|
||||
|
||||
#### Layered Architecture
|
||||
|
||||
Each architectural layer is responsible for a specific concern and communicates through clearly defined boundaries.
|
||||
|
||||
#### Ownership Separation
|
||||
|
||||
Framework-owned capabilities remain separate from application-owned capabilities to prevent implementation leakage and architectural drift.
|
||||
|
||||
#### Extensibility
|
||||
|
||||
Applications extend the framework through approved extension surfaces without modifying framework internals.
|
||||
|
||||
#### Reusability
|
||||
|
||||
Common functionality is implemented once and reused throughout both framework and application layers.
|
||||
|
||||
#### Encapsulation
|
||||
|
||||
Internal framework implementation details remain hidden behind stable interfaces.
|
||||
|
||||
#### Policy-Driven Execution
|
||||
|
||||
Request processing and business operations are governed through dedicated execution pipelines and policy enforcement mechanisms.
|
||||
|
||||
#### Consistency
|
||||
|
||||
Request handling, response generation, execution patterns, and resource management follow standardized conventions throughout the framework.
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### High-Level Structure
|
||||
|
||||
```text
|
||||
source
|
||||
├── data
|
||||
├── essential
|
||||
├── operational
|
||||
└── run
|
||||
```
|
||||
|
||||
The architecture is organized into four primary layers that collectively provide resource management, reusable framework capabilities, application capabilities, policy enforcement, and runtime execution.
|
||||
|
||||
---
|
||||
|
||||
### Data Layer
|
||||
|
||||
The Data Layer stores all framework-owned and application-owned resources.
|
||||
|
||||
```text
|
||||
source/data
|
||||
├── framework
|
||||
│ ├── metadata
|
||||
│ └── glossary
|
||||
└── application
|
||||
├── metadata
|
||||
└── glossary
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Store framework metadata and configuration resources.
|
||||
- Store framework glossary and terminology resources.
|
||||
- Store application metadata and configuration resources.
|
||||
- Store application glossary and terminology resources.
|
||||
- Provide centralized resource ownership boundaries.
|
||||
|
||||
#### Ownership
|
||||
|
||||
| Area | Owner |
|
||||
|--------|--------|
|
||||
| data/framework | Framework |
|
||||
| data/application | Application |
|
||||
|
||||
---
|
||||
|
||||
### Essential Layer
|
||||
|
||||
The Essential Layer contains reusable framework capabilities, infrastructure services, request processing capabilities, and shared functionality.
|
||||
|
||||
```text
|
||||
source/essential
|
||||
├── exchange
|
||||
├── hidden
|
||||
└── visible
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Essential Exchange
|
||||
|
||||
Provides the framework API interaction model.
|
||||
|
||||
```text
|
||||
exchange
|
||||
├── router
|
||||
├── request
|
||||
├── response
|
||||
└── imperative
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- API request routing.
|
||||
- Request processing.
|
||||
- Response generation.
|
||||
- Imperative execution.
|
||||
- Framework-level API orchestration.
|
||||
|
||||
---
|
||||
|
||||
### Essential Hidden
|
||||
|
||||
Contains internal framework capabilities that are not intended for application consumption.
|
||||
|
||||
```text
|
||||
hidden
|
||||
└── service
|
||||
└── management
|
||||
```
|
||||
|
||||
#### Management
|
||||
|
||||
Framework runtime management capabilities.
|
||||
|
||||
```text
|
||||
management
|
||||
├── initialize
|
||||
├── lifecycle
|
||||
├── config
|
||||
├── monitor
|
||||
└── cleaner
|
||||
```
|
||||
|
||||
##### Initialize
|
||||
|
||||
Responsible for framework and runtime initialization.
|
||||
|
||||
##### Lifecycle
|
||||
|
||||
Responsible for:
|
||||
|
||||
- Startup
|
||||
- Shutdown
|
||||
- Restart operations
|
||||
|
||||
##### Config
|
||||
|
||||
Responsible for runtime configuration management.
|
||||
|
||||
##### Monitor
|
||||
|
||||
Responsible for runtime health and operational monitoring.
|
||||
|
||||
##### Cleaner
|
||||
|
||||
Responsible for maintenance and cleanup operations.
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Runtime initialization.
|
||||
- Lifecycle management.
|
||||
- Runtime configuration.
|
||||
- Monitoring and observability.
|
||||
- Maintenance operations.
|
||||
|
||||
---
|
||||
|
||||
### Essential Visible
|
||||
|
||||
Contains reusable framework capabilities available to applications.
|
||||
|
||||
```text
|
||||
visible
|
||||
└── service
|
||||
└── helper
|
||||
```
|
||||
|
||||
Available helper capabilities include:
|
||||
|
||||
```text
|
||||
retriever
|
||||
status
|
||||
log
|
||||
progress
|
||||
filesystem
|
||||
datetime
|
||||
marker
|
||||
key
|
||||
hash
|
||||
cipher
|
||||
codec
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Resource retrieval.
|
||||
- Status reporting.
|
||||
- Structured logging.
|
||||
- Progress tracking.
|
||||
- Filesystem operations.
|
||||
- Date and time utilities.
|
||||
- Identifier generation.
|
||||
- Key generation.
|
||||
- Hash calculation and comparison.
|
||||
- Encryption and decryption.
|
||||
- Encoding and decoding.
|
||||
|
||||
---
|
||||
|
||||
### Operational Layer
|
||||
|
||||
The Operational Layer contains all application-specific behavior, business capabilities, and policy definitions.
|
||||
|
||||
```text
|
||||
source/operational
|
||||
├── exchange
|
||||
├── pipeline
|
||||
└── service
|
||||
```
|
||||
|
||||
This is the primary application development area.
|
||||
|
||||
---
|
||||
|
||||
### Operational Exchange
|
||||
|
||||
Provides the application API interaction model.
|
||||
|
||||
```text
|
||||
exchange
|
||||
├── router
|
||||
├── request
|
||||
├── response
|
||||
└── imperative
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Application request routing.
|
||||
- Application request processing.
|
||||
- Application response generation.
|
||||
- Imperative execution.
|
||||
- Application-level API orchestration.
|
||||
|
||||
---
|
||||
|
||||
### Operational Pipeline
|
||||
|
||||
Contains application-defined policy execution capabilities.
|
||||
|
||||
```text
|
||||
pipeline
|
||||
└── policy
|
||||
├── validation
|
||||
└── ratelimit
|
||||
```
|
||||
|
||||
#### Validation
|
||||
|
||||
Responsible for request validation policies.
|
||||
|
||||
Examples:
|
||||
|
||||
- Schema validation
|
||||
- Payload validation
|
||||
- Business rule validation
|
||||
|
||||
#### Rate Limit
|
||||
|
||||
Responsible for request throttling and usage control.
|
||||
|
||||
Examples:
|
||||
|
||||
- Client limits
|
||||
- Endpoint limits
|
||||
- Resource protection
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Request validation.
|
||||
- Request throttling.
|
||||
- Policy definition.
|
||||
- Application-specific execution controls.
|
||||
|
||||
---
|
||||
|
||||
### Operational Service
|
||||
|
||||
Contains application-specific business capabilities.
|
||||
|
||||
```text
|
||||
service
|
||||
└── [service]
|
||||
└── [feature]
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
service
|
||||
├── user
|
||||
│ ├── create
|
||||
│ └── delete
|
||||
├── customer
|
||||
│ └── register
|
||||
└── invoice
|
||||
└── generate
|
||||
```
|
||||
|
||||
Feature structure:
|
||||
|
||||
```text
|
||||
service
|
||||
└── user
|
||||
└── create
|
||||
├── function.go
|
||||
└── function-data.json
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Implement business rules.
|
||||
- Manage application workflows.
|
||||
- Execute domain-specific operations.
|
||||
- Consume reusable framework capabilities.
|
||||
|
||||
---
|
||||
|
||||
### Runtime Layer
|
||||
|
||||
The Runtime Layer initializes, secures, coordinates, and executes API requests.
|
||||
|
||||
```text
|
||||
source/run
|
||||
├── exchange
|
||||
├── pipeline
|
||||
└── main
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Runtime Exchange
|
||||
|
||||
Receives incoming requests and dispatches execution.
|
||||
|
||||
```text
|
||||
exchange
|
||||
├── router
|
||||
├── request
|
||||
├── response
|
||||
└── imperative
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Runtime request handling.
|
||||
- Request dispatching.
|
||||
- Response delivery.
|
||||
- Execution coordination.
|
||||
|
||||
---
|
||||
|
||||
### Runtime Pipeline
|
||||
|
||||
Provides execution-time access control and policy enforcement.
|
||||
|
||||
```text
|
||||
pipeline
|
||||
├── access
|
||||
└── policy
|
||||
```
|
||||
|
||||
#### Access
|
||||
|
||||
Access control pipeline.
|
||||
|
||||
```text
|
||||
access
|
||||
├── authentication
|
||||
└── authorization
|
||||
```
|
||||
|
||||
##### Authentication
|
||||
|
||||
Verifies the identity of the request originator.
|
||||
|
||||
Examples:
|
||||
|
||||
- API Keys
|
||||
- JWT Tokens
|
||||
- Session Authentication
|
||||
|
||||
##### Authorization
|
||||
|
||||
Determines whether authenticated entities can access requested resources.
|
||||
|
||||
Examples:
|
||||
|
||||
- Role-based access control
|
||||
- Permission-based access control
|
||||
- Scope validation
|
||||
|
||||
#### Policy
|
||||
|
||||
Responsible for runtime policy enforcement.
|
||||
|
||||
```text
|
||||
policy
|
||||
└── enforce.go
|
||||
```
|
||||
|
||||
Responsibilities:
|
||||
|
||||
- Execute policy decisions.
|
||||
- Enforce validation outcomes.
|
||||
- Enforce access decisions.
|
||||
- Coordinate runtime controls.
|
||||
|
||||
---
|
||||
|
||||
### Runtime Main
|
||||
|
||||
Application bootstrap and startup.
|
||||
|
||||
```text
|
||||
main
|
||||
└── main.go
|
||||
```
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
- Framework initialization.
|
||||
- Application initialization.
|
||||
- Runtime startup.
|
||||
- Lifecycle coordination.
|
||||
- API server bootstrap.
|
||||
|
||||
---
|
||||
|
||||
### Request Lifecycle
|
||||
|
||||
The framework follows a layered request processing model.
|
||||
|
||||
```text
|
||||
Client Request
|
||||
│
|
||||
▼
|
||||
Runtime Exchange
|
||||
│
|
||||
▼
|
||||
Access Pipeline
|
||||
(Authentication / Authorization)
|
||||
│
|
||||
▼
|
||||
Policy Enforcement
|
||||
│
|
||||
▼
|
||||
Application Exchange
|
||||
│
|
||||
▼
|
||||
Application Policies
|
||||
(Validation / Rate Limiting)
|
||||
│
|
||||
▼
|
||||
Application Service
|
||||
│
|
||||
▼
|
||||
Framework Services
|
||||
│
|
||||
▼
|
||||
Resource Layer
|
||||
│
|
||||
▼
|
||||
Response
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Ownership Model
|
||||
|
||||
| Layer | Owner | Responsibility |
|
||||
|---------|---------|---------|
|
||||
| data/framework | Framework | Framework resources |
|
||||
| data/application | Application | Application resources |
|
||||
| essential | Framework | Reusable framework capabilities |
|
||||
| operational | Application | Business capabilities and policies |
|
||||
| run | Framework | Runtime execution and enforcement |
|
||||
|
||||
---
|
||||
|
||||
### Extension Surface
|
||||
|
||||
Applications are expected to extend the framework through the following locations:
|
||||
|
||||
```text
|
||||
source/data/application
|
||||
source/operational
|
||||
```
|
||||
|
||||
Applications should consume reusable framework capabilities from:
|
||||
|
||||
```text
|
||||
source/essential/visible
|
||||
```
|
||||
|
||||
Applications should not directly depend on:
|
||||
|
||||
```text
|
||||
source/essential/hidden
|
||||
```
|
||||
|
||||
as these components are considered internal framework implementation details and may change without notice.
|
||||
Loading…
Reference in New Issue
Block a user