Support existing Lakehouse/Warehouse as a data source for the GraphQL data API (no DAX, no copy)

Problem statement

I have started experimenting with building a Fabric App, and need to read existing data from our Lakehouse/Warehouse. Today the only built-in path appears to be connecting a semantic model and querying it with DAX (and the docs frame data integration as "starting with Semantic Models."). Are there plans to add other first-party ways to bring existing OneLake/Warehouse/Lakehouse data into a Fabric App without copying it into the app's built-in database (e.g. a native connector to the SQL analytics endpoint or API for GraphQL)?

Proposed solution

Allow declaring an existing Lakehouse/Warehouse SQL analytics endpoint as a
data source in rayfin.yml, so the data service generates its GraphQL (DAB)
API over those existing tables instead of only the app-owned schema,
queryable via RayfinClient with the app's existing Fabric SSO. No copying
into the built-in DB, no semantic model/DAX.

Also expose stored procedures (and views) on the source as GraphQL
operations, so server-side SQL (aggregations etc.) is callable by name with
arguments.

In short: the Supabase (Lovable) model applied to existing Fabric data, auto-generated
API over an existing SQL database (PostgREST equivalent) plus stored procedures
as the RPC equivalent (supabase.rpc()), with the app's auth + RLS.

Alternatives considered

• Semantic model + DAX (the current built-in path) — prefer SQL; DAX also
  has weaker tooling and far less training data, so AI-assisted/agentic
  development performs worse.
• Standalone "API for GraphQL" item alongside the app — works, but it's a
  separate item with no built-in integration: the embedded app only gets a
  Rayfin OpaqueSession, not an Entra token for the separate endpoint, so
  cross-item auth has to be solved by hand.
• Copy/sync existing data into the app's built-in DB (ETL) — duplicates
  governed Gold data, needs a sync pipeline, and goes stale.
• Custom function querying the Lakehouse SQL endpoint — works, but it's
  bespoke per-app code to build and maintain.

Additional context

I built a fully fledged analytics tool in lovable using their native supabase integration and would like to do something similar in fabric apps. I dont like having to rely on DAX since I feel much more comfortable with SQL, plus the fact that agentic development with DAX is harder due to limited training data which means poorer performance from AI agents.

I think this would be a huge value add to fabric apps as a concept, especially for greenfield projects (like mine) where business logic is baked into RPCs and edge functions rather than semantic models.

Begin with the proposed rayfin.yml data-source declaration and the RayfinClient path, then review how the SQL analytics endpoint could support the GraphQL (DAB) API. Done means existing Lakehouse/Warehouse tables, views, and stored procedures are exposed without copying data, while Fabric SSO and app authentication with RLS remain intact.