fmacias/tplqueue-overview
Cross-repository TplQueue integration guidance for choosing packages, composing Core and Adapter, dependency injection, ASP.NET/SignalR, legacy .NET applications, DataJobs, payload handlers and cache providers.
Select TplQueue NuGet packages for a concrete consumer workload, including direct Core use, the Adapter facade, Microsoft DI, retries, observers, serializers, and cache providers. Use for package selection and dependency composition, not package implementation changes.
Compose IDataJob/IDataJobRoot, payload identity and HandlerKey routing, Adapter handler registration, serializers, cache factories, and CacheQ from the application boundary. Use for direct versus rehydrated DataJob integration, not private CacheQ implementation or detailed runtime semantics.
Compose TplQueue in an application with or without Microsoft DI, choose narrow injected interfaces, and assign queue/runtime ownership. Use for host-independent integration and shared queue lifetime questions, not detailed Core lifecycle or Adapter modification procedures.
Explain current AddTplQueue registrations and lifetimes, configuration snapshots, narrow service injection, and application-owned queue/cache/handler composition. Use for consuming Microsoft DI integration, not changing its implementation.
Adopt TplQueue incrementally in .NET Framework or legacy .NET applications, validate the package graph, retain an existing composition root or IoC container, and marshal observer updates to WinForms/WPF UI threads. Use for legacy integration without requiring migration to modern .NET.
Integrate TplQueue with ASP.NET Core, hosted services, HTTP endpoints, and SignalR using application-owned queues and observer-to-DTO transport projection. Use for web hosting and notification composition, not detailed Core observation semantics or sample-specific architecture changes.
Explain TplQueue package and repository boundaries, CoreApi versus Adapter IApi, construction versus execution responsibilities, and the separate Core licensing boundary. Use for consumer architecture and adoption questions, not private Core implementation or repository modification workflows.