Add support for Graphql API

[asmajlovicmars]

Feature Spec

The concept is similar, if not identical, to the Amplify GraphQL API, which offers queries, mutations, and real-time event subscriptions.

The GraphQL API facilitates several essential steps for expedited development:

• It defines a data model.
• Establishes a detailed and robust security mechanism through data authorization.
• Automatically initializes a database with associated NoSQL tables.
• Uses code generation to produce GraphQL queries, mutations, and subscriptions.
• Permits the definition of custom mutations that can invoke other services, such as a workflow (using StepFunctions) or a function, among others.

Regarding the @ directives:

• The @ model directive implicitly creates a NoSQL table that supports the GraphQL API.
• @ auth determines the rules for data access.
• @ searchable establishes a connection and facilitates open text searches.
• @ function links lambda resolvers to the API.

References:

• Graphql API Construct
• API (GRAPHQL)

Use Cases

This would give us lot of benefits for Rapid Development:

• Simplified Data Model Creation: By defining a data model directly, you reduce the need for intricate database design processes.
• Robust Security: With granular data authorization, you ensure data security without having to custom-code permissions.
• Automatic Database Initialization: Instead of manual database setups, it auto-generates associated NoSQL tables, reducing the time-to-launch.
• Code Generation: Automatically produces GraphQL queries, mutations, and subscriptions, which means less manual coding and fewer errors.
• Flexibility with Custom Mutations: Easily integrate with other Cloud services or functionalities, speeding up the development of complex features.
• Clear Directives for Functionality: Using @ directives like @model, @auth, @searchable, and @function, you can intuitively specify functionality, which streamlines the development process.

Boost in Rapid Development:

• Reduced Setup Time: Eliminating manual tasks like database setup accelerates project initiation.
• Consistency: Code generation ensures uniformity, which can lead to fewer bugs and less debugging time.
• Integrated Ecosystem: Being part of the desired cloud ecosystem, it's easier and faster to integrate with other services.
• Scalability: The underlying cloud infrastructure ensures that as your application grows, scaling won't be a bottleneck, allowing for consistent rapid development.

In essence, the GraphQL API acts as a catalyst, streamlining many traditional development tasks and allowing for a focus on feature development and business logic, ultimately accelerating the overall development process.

Implementation Notes

These two references could be helpful as a starting point:

• Graphql API Construct
• API (GRAPHQL)

Component

SDK

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.
• If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out on the #dev channel in the Wing Slack.

[staycoolcall911]

Amazing - I'm adding this to the Wing Standard Library Roadmap instead of #2155 (closing #2155 as a duplicate).

Copying over an important remark from #2155 by @olivernybroe:

I think a new resource under cloud would be cleanest I think, e.g.

bring cloud;

let gql = new cloud.Gql('schema.gql');

gql.mutation("createPost", inflight (request: cloud.GqlRequest): cloud.GqlResponse => {
    return cloud.GqlResponse {
        title: "My title"
    };
});

[garysassano]

I've read the related blog post about this L3 construct and honestly I believe Wing should avoid opting for an opinionated solution using a pre-packaged bundle of resources. It would be more appropriate for the end user to craft such a bundle independently.

[eladb]

I've read the related blog post about this L3 construct and honestly I believe Wing should avoid opting for an opinionated solution using a pre-packaged bundle of resources. It would be more appropriate for the end user to craft such a bundle independently.

Not sure I fully understand. Can you elaborate or provide an example?

[garysassano]

It seemed to me that Wing preferred not to depend on third-party constructs. In the past, when I brought up the idea of using the openapix L2 construct for the API Gateway, I was told that a PR including it would likely not be approved.

Also, I'm left with two unresolved questions:

• Is there an easy way to convert an AWS CDK construct into a CDKTF construct?
• What benefits does incorporating this into Wing offer? Couldn’t users simply import the construct on their own?

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!