|
| 1 | +# Embedded Cluster API Package |
| 2 | + |
| 3 | +This package provides the core API functionality for the Embedded Cluster system. It handles installation, authentication, console access, and health monitoring of the cluster. |
| 4 | + |
| 5 | +## Package Structure |
| 6 | + |
| 7 | +### Root Level |
| 8 | +The root directory contains the main API setup files and request handlers. |
| 9 | + |
| 10 | +### Subpackages |
| 11 | + |
| 12 | +#### `/controllers` |
| 13 | +Contains the business logic for different API endpoints. Each controller package focuses on a specific domain of functionality (e.g., authentication, console, installation) and implements the core business logic for that domain. |
| 14 | + |
| 15 | +#### `/types` |
| 16 | +Defines the core data structures and types used throughout the API. This includes: |
| 17 | +- Request and response types |
| 18 | +- Domain models |
| 19 | +- Custom error types |
| 20 | +- Shared interfaces |
| 21 | + |
| 22 | +#### `/pkg` |
| 23 | +Contains shared utilities and helper packages that provide common functionality used across different parts of the API. This includes both general-purpose utilities and domain-specific helpers. |
| 24 | + |
| 25 | +#### `/client` |
| 26 | +Provides a client library for interacting with the API. The client package implements a clean interface for making API calls and handling responses, making it easy to integrate with the API from other parts of the system. |
| 27 | + |
| 28 | +## Where to Add New Functionality |
| 29 | + |
| 30 | +1. **New API Endpoints**: |
| 31 | + - Add route definitions in the root API setup |
| 32 | + - Create corresponding controller in `/controllers` |
| 33 | + - Define request/response types in `/types` |
| 34 | + |
| 35 | +2. **New Business Logic**: |
| 36 | + - Place in appropriate controller under `/controllers` |
| 37 | + - Share common logic in `/pkg` if used across multiple controllers |
| 38 | + |
| 39 | +3. **New Types/Models**: |
| 40 | + - Add to `/types` directory |
| 41 | + - Include validation and serialization methods |
| 42 | + |
| 43 | +4. **New Client Methods**: |
| 44 | + - Add to appropriate file in `/client` |
| 45 | + - Include corresponding tests |
| 46 | + |
| 47 | +5. **New Utilities**: |
| 48 | + - Place in `/pkg/utils` if general purpose |
| 49 | + - Create new subpackage under `/pkg` if domain-specific |
| 50 | + |
| 51 | +## Best Practices |
| 52 | + |
| 53 | +1. **Error Handling**: |
| 54 | + - Use custom error types from `/types` |
| 55 | + - Include proper error wrapping and context |
| 56 | + - Maintain consistent error handling patterns |
| 57 | + |
| 58 | +2. **Testing**: |
| 59 | + - Write unit tests for all new functionality |
| 60 | + - Include integration tests for API endpoints |
| 61 | + - Maintain high test coverage |
| 62 | + |
| 63 | +3. **Documentation**: |
| 64 | + - Document all public types and functions |
| 65 | + - Include examples for complex operations |
| 66 | + - Keep README updated with new functionality |
| 67 | + |
| 68 | +4. **Logging**: |
| 69 | + - Use the logging utilities from the root package |
| 70 | + - Include appropriate log levels and context |
| 71 | + - Follow consistent logging patterns |
| 72 | + |
| 73 | +## Architecture Decisions |
| 74 | + |
| 75 | +1. **Release Metadata Independence**: |
| 76 | + - The EC API should not use the release metadata embedded into the EC binary (CLI) |
| 77 | + - This design choice enables better testability and easier iteration in the development environment |
| 78 | + - API components should be independently configurable and testable |
| 79 | + |
| 80 | +## Integration |
| 81 | + |
| 82 | +The API package is designed to be used as part of the larger Embedded Cluster system. It provides both HTTP endpoints for external access and a client library for internal use. |
| 83 | + |
| 84 | +For integration examples and usage patterns, refer to the integration tests in the `/integration` directory. |
0 commit comments