Initial FDC resolver support in functions SDK.

[rosalyntan]

Description

Implement the onGraphRequest helper function for building a Firebase Data Connect resolver detailed in go/fdc-webhooks-functions-api.

Code sample

import { onGraphRequest } from 'firebase-functions/dataconnect';

const opts = {
    schemaFilePath: "schema.gql",
    // or schema: "type Query { hello(name: String): String }",
    resolvers: {
        query: {
            hello(parent, args, contextValue, info) {
                return `Hello ${args.name}!`;
            },
        },
    },
}
exports.resolver = onGraphRequest(opts);

[gemini-code-assist]

Summary of Changes

Hello @rosalyntan, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces foundational support for Firebase Data Connect (FDC) resolvers within the Firebase Functions SDK. It provides a new entry point, onGraphRequest, for developers to easily set up and deploy GraphQL servers as HTTPS functions. By integrating with Apollo Server, this change offers a structured way to define GraphQL schemas and resolvers, streamlining the development of GraphQL-based APIs on Firebase.

Highlights

• FDC Resolver Support: Introduced initial support for Firebase Data Connect (FDC) resolvers within the functions SDK, enabling the creation of GraphQL APIs.
• GraphQL Server Function: Added a new onGraphRequest function that allows developers to define and deploy GraphQL servers as HTTPS functions.
• Apollo Server Integration: Integrated ApolloServer and @as-integrations/express4 to provide robust GraphQL server capabilities, including schema definition and resolver mapping.
• Dependency Updates: Updated package.json and package-lock.json to include @apollo/server and @as-integrations/express4 as optional peer dependencies, along with their transitive dependencies.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces initial support for Firebase Data Connect (FDC) resolvers via a new onGraphRequest function. This allows developers to create GraphQL endpoints. My review focuses on the implementation of onGraphRequest and its associated options. I've identified a critical issue with how optional dependencies are handled, which will cause runtime errors. I've also found some bugs related to handling server options, such as ignoring the customizable path and schema file path. Additionally, there are some areas for improvement in the options interface and a hardcoded value that needs clarification.

[taeold]

nit* curious if this type can be tightened to match expecations of ApolloServer instead of it being a generic object.

also nit, I usually prefer using Record, e.g. Record<string, any>

[taeold]

hmm it looks like this should be GraphqlResolvers type we defined below, with the change that query -> Query and mutation -> Mutation?

[rosalyntan]

The reason we're not directly using ApolloServer's types here is for future extensibility, for example the developer could pass in an option to use the graphql-http library instead.

[taeold]

do you want to leave this todo?

[rosalyntan]

This wasn't included in the original API proposal, so wanted to run it by you and the council (maybe in an email follow-up) before adding this field.

[taeold]

you may have noticed that most of trigger options ends up repeating the common options... this is because we learned that our reference doc generation doesn't show the full range of options that's available in the parent type (in this case HttpOptions).

For better reference docs, we might want to repeat all the available options for the graphql server options here.

[rosalyntan]

So looking at https://firebase.google.com/docs/reference/functions/2nd-gen/node/firebase-functions.https.httpsoptions.md, it looks like it does link to the parent type which I think seems sufficient (and I think this also makes the GraphQL-specific options more visible to developers).

On a related note, if we're ignoring CORS configuration with these options, should I do something like Omit<GlobalOptions, "cors"> here?