Extend the PlatformCustom Adapters
Custom Adapters
Build your own KV, queue, search, realtime, storage, and email adapters for QUESTPIE.
Almost every infrastructure layer in QUESTPIE is swappable. Each subsystem defines a contract (interface or base class) that you implement, then register in your questpie.config.ts. QUESTPIE calls your adapter through that contract -- it never cares which provider sits behind it.
Adapter types
| Type | Contract | Config key | Default |
|---|---|---|---|
| KV / Cache | KVAdapter interface | kv.adapter | MemoryKVAdapter |
| Queue | QueueAdapter interface | queue.adapter | PgBossAdapter |
| Search | SearchAdapter interface | search | PostgresSearchAdapter |
| Realtime | RealtimeAdapter interface | realtime.adapter | polling (no adapter) |
| Storage | FlyDrive DriverContract | storage.driver | FSDriver (local disk) |
MailAdapter abstract class | email.adapter | ConsoleAdapter |
Before you start
A good custom adapter should follow three rules:
- Keep the adapter thin. Translate QUESTPIE calls to your provider SDK, but do not move business logic into the adapter.
- Match the contract exactly. If a method returns
Promise<void>orPromise<string | null>, keep it that way. - Start with an in-memory fake. It is the fastest way to test behavior before wiring up a real provider.
Recommended workflow
- Implement the contract against an in-memory fake.
- Write adapter-only tests for success, errors, and cleanup.
- Wrap the real provider SDK.
- Register it in
questpie.config.ts. - Add one integration test that exercises the real QUESTPIE runtime path.