| name | aidd-service |
| description | Enforces asynchronous data service authoring best practices. Use when creating front-end or back-end services, service interfaces, Observe patterns, AsyncDataService, or when the user asks about service layer, data flow, unidirectional UI, or action/observable design. |
Service authoring
Asynchronous data services. Live in the services/ layer per structure. Adhere to namespace for type and function organization.
Data = readonly JSON values or Blobs.
Front-end vs back-end services
FrontEndService {
allowed: ["Observe<Data>", "other services (sub-Services)", "void-returning action functions"]
notAllowed: ["Promise or AsyncGenerator return"]
}
BackEndService {
typicallyReturns: "Promise<Data> | AsyncGenerator<Data>"
notCalledFrom: "UI"
calledBy: "front-end services"
}
Constraints {
UI components: unidirectional path — data down via void actions, data up via Observe
}
Back-end services — usually stateless. Functions typically return Promise<Data> or AsyncGenerator<Data>. Not called directly from UI; front-end services call them.
Front-end service constraints
ServiceInterfaceForUI {
mayContain: [
"Observe<Data> — observable properties or factories",
"Sub-Services — nested service interfaces",
"Action functions — zero or more Data arguments, return void only",
"Factory functions — create observables or sub-Services"
]
observablesMayObserve: ["Data", "Service interfaces only"]
compileTimeCheck: "Assert<AsyncDataService.IsValid<ServiceInterface>>"
}
Benefits
- Unidirectional flow — data down via actions, data up via Observe
- Async isolation — view and service decoupled