Understand the fundamental concepts and architecture of RouteMQ.
- Framework Architecture - Overall system design
- Router Discovery - How routes are loaded
- Message Flow - How messages are processed
- Middleware Pipeline - Request processing chain
- Worker Processes - Shared subscriptions and scaling
RouteMQ follows a modular architecture inspired by web frameworks:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ MQTT Broker │◄──►│ RouteMQ App │◄──►│ External │
│ │ │ │ │ Services │
│ - Message Queue │ │ - Route Handler │ │ - Database │
│ - Pub/Sub │ │ - Middleware │ │ - Redis │
│ - Load Balance │ │ - Workers │ │ - APIs │
└─────────────────┘ └─────────────────┘ └─────────────────┘
- Discovers and loads route files automatically
- Manages route definitions and middleware
- Handles shared subscriptions
- Processes messages before reaching handlers
- Supports authentication, rate limiting, logging
- Chainable and reusable components
- Handle business logic for routes
- Async/await support for non-blocking operations
- Direct access to Redis, database, and MQTT client
- Manages shared subscription workers
- Provides horizontal scaling for high-throughput routes
- Load balancing across multiple processes
- Message Arrives: MQTT broker receives message
- Route Matching: Framework matches topic to registered routes
- Middleware Chain: Message passes through middleware pipeline
- Parameter Extraction: Route parameters extracted from topic
- Handler Execution: Controller method processes the message
- Response: Optional response published back to MQTT
- Convention over Configuration: Sensible defaults with customization options
- Async First: Built for non-blocking I/O operations
- Modular: Loosely coupled components
- Scalable: Horizontal scaling through shared subscriptions
- Testable: Easy to unit test and mock dependencies
- Router Discovery - Learn how routes are loaded
- Message Flow - Understand message processing
- Getting Started - Build your first route