Unified Data Sources

Components need data. Where that data comes from varies enormously: your own database, an external API, a monitoring service, a static configuration, a computed result. In most systems, each data source type requires different handling code. A database query looks different from an API call. An API call looks different from a static list.

Swifty's unified data source interface means every data source looks the same to the components consuming it.

One Contract for All Data

A data source in Swifty implements a single contract: given a configuration and optional filters, return a list of items. Each item has an ID and a set of fields. That's the entire interface.

Whether the underlying implementation is a database query, an API call to an external service, a monitoring endpoint, or a static in-memory list — the component receiving the data doesn't know or care. It requests data through the unified interface and receives items in a consistent shape.

What This Enables

This uniformity has concrete consequences for how you build:

Any component works with any data source. A table component, a metrics card, a chart — all of them consume data sources. Because data sources all speak the same language, you can connect a chart to an API data source just as easily as to your own database. The component wasn't built for that source specifically; it was built to consume the unified interface.

Filtering and sorting work everywhere. The data source interface includes standard operations: filter by field, sort, paginate. Implementations handle these operations in whatever way makes sense for the backend — a SQL WHERE clause for databases, query parameters for APIs. Components issue the same filtering calls regardless.

Switching sources doesn't break components. Point a component at a different data source and it continues to work. Configuration changes; behavior doesn't.

Built-In Source Types

Swifty ships with data source implementations for common backends:

• Database objects (your application's records)
• External API integrations (configured per-workspace)
• Static item lists (for configuration-driven content)
• Monitoring and metrics endpoints
• Computed and composed sources (combining multiple sources)

Custom Sources via Extensions

The extension system allows adding new data source types. An extension that connects to a specific service can register its data source implementation against the unified interface. Any component in the platform can then use it without modification.

The uniformity isn't a constraint — it's an expansion. Every new source type immediately becomes available to every existing component.