Data Connect Queries: From Definitions to Client Code in Firebase: Web Architecture & Implementation Guide

Q: What is a Data Connect query?

A Data Connect query is a GraphQL query: an operation that asks about specific fields from a backend datastore defined by your schema. You write queries in GraphQL, and you can use queries: in your client apps, only after you’ve deployed the queries to production for ad hoc execution from privileged environments like the Visual Studio Code extension, the Firebase console, and the Firebase Admin SDK. Deployment of the queries is not required for these actions.

If you have ever watched an AI coding agent hallucinate deprecated Firebase v8 syntax or deploy wide-open Firestore rules, you know that raw LLM prompts are not enough for production backends. Following the announcement of Data Connect Queries: From Definitions to Client Code by Andrea Wu on the Official Firebase Blog (2025-05-01), here is our hands-on CodingCat.dev breakdown of what actually shipped, how it works under the hood, and how we wire it into production TypeScript, Next.js, Astro, SvelteKit, React, and Angular applications. Note: Firebase Data Connect has been renamed to SQL Connect. Learn more in the SQL Connect announcement.

The Mental Model: Why Data Connect Queries: From Definitions to Client Code Matters for Web Devs

As a Google Developer Expert (GDE) for Firebase and Senior Solutions Engineer at CodingCat.dev, I evaluate every Firebase update through one lens: does it reduce boilerplate while keeping our runtime security and cloud bills predictable? Instead of relying on stale training weights, wiring up the Model Context Protocol (MCP) and structured Firebase agent skills gives your IDE or CLI direct, schema-aware tools to provision resources, inspect security rules, and run deterministic CLI deployments.

AJ Pro-Tip from Alex: Never let an autonomous coding agent push Firestore or Data Connect rules straight to production without a gate. Always require the agent to run your test suite against the Firebase Local Emulator Suite first, and audit every generated rule for strict request.auth.uid ownership checks.

How It Works: Technical Breakdown & Implementation

A big part of any database solution is seamlessly getting information that you may need for your app. With Data Connect, you set up schemas to model your data, and then you make queries on that data. This blog post will dive into queries, and we’ll assume that you are familiar with schemas. Feel free to read the Data Connect documentation if you need a reminder.

We’ll use the movie review app example you might already know from the documentation and our previous deep-dive blog posts.

What is a Data Connect query?

A Data Connect query is a GraphQL query: an operation that asks about specific fields from a backend datastore defined by your schema. You write queries in GraphQL, and you can use queries:

in your client apps, only after you’ve deployed the queries to production
for ad hoc execution from privileged environments like the Visual Studio Code extension, the Firebase console, and the Firebase Admin SDK. Deployment of the queries is not required for these actions.

Declaring a Query

These are the parts of a query definition in GraphQL:

Zero, one, or more than one operation argument

Here is an example to list all movies by genre:

A query type definition, letting GraphQL know this is a query
A ListMoviesByGenre operation (query) name
A single variable $genre operation argument of the String type. Every query argument requires a type declaration, a built-in supported data type like String, or a custom, schema-defined type like Movie_Key (which is a key scalar).
A single directive, @auth, which specifies only logged-in users, can execute this query. For this movie data that’s appropriate for public viewing, the PUBLIC level is sufficient authorization.

Anatomy of a Query

Now that we know how to declare a query, what does a query in its entirety look like? It is broken down into the following parts:

Declaration to create a query, as described in the previous section
Tables from which the query needs to get data

Here is an example query to get all movies of a particular genre ordered by highest rating to lowest:

query 
  mostPopular: 
     where: { genre: { eq: $genre } }, orderBy: { rating: DESC }
  ) {
    id
    title
    genre
    description
  }
}

The first line is described in the “Declaring a Query” section. Let's break down the other important pieces:

movies specifies the table in the schema from which the query needs to get data
where and orderBy are filters applied to retrieving the data
id, title, genre, and description are the fields to be returned by this query for all of the movies that fit the genre

Directives

Let’s talk about directives - like @auth. Data Connect has three directives for queries to define their behavior:

@auth defines the authentication policy, and it is required for the query to be accessible by client apps
@check verifies that specified fields are present in query results
@redact omits query results from the client’s response

For more information, there are more in-depth descriptions and resources in the documentation about directives for queries.

Generated Fields

When you create a schema, Data Connect’s local tooling automatically generates fields based on the types and type relationships in your schema. These generated fields are necessary for writing your own queries to be deployed and used in your client code, or run ad hoc in privileged environments

As an example of a generated field, say the Movie type is defined as:

type
  id: UUID! @default(expr: "uuidV4()")
  title: String!
  releaseYear: Int @index
  genre: String @col(dataType: "varchar(30)")
  rating: Int
  description: String
}

With the schema definition, Data Connect generates fields for single-table use cases, as seen in query.gql. It creates a field to get:

a singular record from the Movie table, given the id for the movie. The field name is the same as the table name, unless otherwise defined - movie in this case.
a list of movies, given optional filtering conditions. The field name is the same as the table name with a “s” at the end, unless otherwise defined - movies in this case.

(In both of these tables, a directive that this blog post didn’t cover is @fdc_generated - you will never be writing this on your own, so don’t worry too much about it. It says which table the generated field is coming from and whether it’s querying for a single record or multiple records).

Data Connect also generates fields for multi-table, relational operations with explicit names. This will be in a future blog post, as there is a lot to cover.

Where can I find these fields?

With the Data Connect Visual Studio Code extension, there are several ways to see and use these generated fields after you begin editing your schema:

They are listed under the Schema Explorer
Their source is generated to dataconnect/.dataconnect/main/query.gql
They are browsable in automatic local documentation, accessible with the View reference docs link
They are incorporated into ad hoc queries generated when you click CodeLens buttons

Once you deploy your schema, you can view the generated fields with reference documentation in the Firebase console and use the data tab to prototype queries.

Using Generated Fields for Queries

With the generated fields, you can now write queries to retrieve the information needed for your app. Your client code can only use these queries and not the generated fields. Additionally, the client only gets to see the fields selected in queries. If there’s a secret field that you don’t want clients to see, then clients cannot see it since they don’t have direct access to the database.

For example, you can use the generated movie field to create your own query, where you pass in the movie id:

query 
  movie
    id
    title
    imageUrl
    genre
  }
}

For listing movies, you can use the generated movies field:

query ListMovies @
  movies {
    id
    title
    imageUrl
    genre
  }
}

Using queries

Now that you’ve defined your queries, you’re ready to use them in your app code. How do you do that? Data Connect automatically generates SDKs for you to use, bridging the gap between your queries defined in GraphQL and your application platform. You need to set up these generated SDKs, and then you can call the generated functions in your app code. Feel free to read about what generated SDKs are and how to use them in Data Connect.

Production Web Architecture & Security Checklist

Whether we are deploying on Firebase App Hosting, Cloudflare Workers, or Vercel, shipping SQL features to production requires defense-in-depth across three layers:

Enforce Firebase App Check & Attestation: Protect your web endpoints, Cloud Functions, Data Connect GraphQL resolvers, and Firebase AI Logic calls against unauthorized replay or billing abuse using Firebase App Check with reCAPTCHA Enterprise.
Validate Locally with the Firebase Emulator Suite: Run deterministic integration tests against local Firestore, Auth, Functions, and Data Connect PostgreSQL emulators before promoting schema or rule changes to production.
Keep Server & Client Boundaries Type-Safe: Use the modular Firebase Web SDK and generated TypeScript bindings so SSR frameworks like Next.js, Astro, SvelteKit, and Angular serialize state cleanly without hydration flickers.

Conclusion

Accelerate your full-stack web and AI development by pairing Data Connect Queries: From Definitions to Client Code with strict Security Rules, Firebase App Check, and local emulator testing. Come tell us on X (@CodingCatDev) and LinkedIn (CodingCat.dev) how you are using Firebase in your stack, and subscribe to the CodingCat.dev YouTube Channel so you don't miss what we build next!

Watch Our Related Firebase Video Tutorial on YouTube

Want to see how we architect and debug Firebase web applications live? Watch our related CodingCat.dev session Firebase SQL with Data Connect below, and make sure to Subscribe to CodingCat.dev on YouTube for weekly full-stack web and AI deep dives:

Resources, Official Docs & Related CodingCat.dev Guides

Primary Release Source: Data Connect Queries: From Definitions to Client Code on the Official Firebase Blog (published 2025-05-01 by Andrea Wu)
Official Firebase Documentation: Firebase Developer Docs & Web SDK Reference
Related on CodingCat.dev: Angular and React Bindings for Data Connect
Related on CodingCat.dev: Atomic Data Modifications for Data Connect
Related on CodingCat.dev: Firebase SQL with Data Connect
Related on CodingCat.dev: Build a Custom No-Code App in 90 Minutes

Frequently Asked Questions (FAQ)

What are the key capabilities introduced in Data Connect Queries: From Definitions to Client Code?

Data Connect Queries: From Definitions to Client Code (announced 2025-05-01 by the Firebase team) enhances the platform for Firebase, Google Cloud, Web Dev, SQL, TypeScript, Security workloads. Note: Firebase Data Connect has been renamed to SQL Connect. Learn more in the SQL Connect announcement. Developers can review the primary announcement on the Firebase Blog alongside our implementation patterns and production checklist above.

How do web developers use Data Connect Queries: From Definitions to Client Code with Next.js, SvelteKit, React, or Angular?

Web developers can integrate these features using the modular Firebase JavaScript/TypeScript SDK, Firebase Data Connect web bindings, and Firebase App Hosting. Always pair client-side SDK initialization with Firebase App Check and strict Security Rules, and test locally with the Firebase Local Emulator Suite before deploying.

Where can I watch video tutorials on Firebase Web and AI development?

You can watch our hands-on Firebase video walkthroughs on the CodingCat.dev YouTube Channel, including Firebase SQL with Data Connect, and follow us on X (@CodingCatDev) for weekly full-stack tutorials.