Open JJK801 opened 6 months ago
Hi @JJK801 - first off, WOW! Thanks for putting all this together! Really LOVE the details and the overall workflows. I've got a few follow-up questions:
generateClient
operation within a Node.js environment. That way you'd get the same typing end-to-end no matter what JS environment you run in (SSR function, Node.js, or Browser). Would that also adders your use case? Hi @renebrandel,
Thanks for your reply.
Yes, the solution mentioned in 1 is exactly what i aim to solve, but it must be enough configurable to issue the exact query we expect (so that it match all use cases).
My opinion is that an ideal solution must be "multi staged", i mean there should be many abstraction layers from the more verbose (GraphQL oriented) to the smallest code lines (using syntaxic sugars), so that we can plug in the stage we need to achieve what we want to do (like CDK does) without being limited by the framework.
In my case, i have to deal with many limitations due to the define
functions (which are great to quickly bootstrap an app, but are a pain when we want to integrate custom resources), and i had to reproduce some features (like secret management, which is very usefull), because i can't plug on the logic behind those high level functions and the public API is limited.
In the example above, the builder is very simple is sense of code, because the only thing it handles is formatting the GQL query, anything else is done via the user input, which is driven by the Typescript shape. This is lightweight in the end (once compiled in the lambda function) and it secures developers with the TSC validating that everything is OK, and that's barely what we expect (more than writing less code)
PS: And with the TS-First solution, writing the query is not a pain because Typescript autocompletes almost everything.
Hi @JJK801 - would you be down to hop on a call sometime? I'd love to discuss this more and brainstorm on the DX. If you're open to it, can you DM me on Twitter? https://x.com/renebrandel
Talking to @JJK801. We're brainstorming on an ideal DX for running Amplify in Lambda:
defineData
function. This could eliminate a circular dependency issue. Generally the IAM permissions should be governed by IAM, not another allowAdminRoleNames
property on defineData
. Similarly linked: https://github.com/aws-amplify/amplify-backend/issues/1043client.models.
) notation, we could look into leveraging the good work of https://gql-tada.0no.co/ import { generateNodeClient } from 'aws-amplify/adapter-nodejs'
import type { Schema } from '../../data/resource'
const client = generateNodeClient<Schema>(process.env.AMPLIFY_CONFIGURATION)
// Leverage the existing `models.` notation for fully typed experience.
client.models.Todo.create()
// Execute raw GraphQL queries that are fully typed
client.graphql({
query: /*GraphQL*/ `query ...` // ideally this is a fully typed string
variables: {
filters: {} // the variables and filters should be type matched to the query
}
}
There's an initial DX for this outlined here: https://github.com/aws-amplify/docs/pull/7029 But it still needs more work to be a production-ready solution
@edwardfoyle The initial DX mentions needing to import @env/
transferring this to our API repository.
Hi @JJK801, We are marking this as a feature request for the team to evaluate further.
Environment information
Description
Hi guys 🖖
Today i come with some improvement ideas (i will be back with issues soon 😄 ) about the use of GraphQL in this new amazing Code-First backend.
Root Cause of my tought
I need to use some lambda functions to access data (ideally by using AppSync to take advantage of subscriptions), so after some hours (days) wiring everything (thanks to @edwardfoyle for his help here), i got stuck on handling my GraphQL queries, because the codegen can only run after i deploy my app (so i cant use this feature to make sure my queries are up to date with data).
My first approach was "okay, lets rewrite the queries in my handlers", and, 2 deploys later: "F***, i missed updating my query in the handler", so i figured that it's really not a professional way as we can't cover it with tests or static checks.
Solution
What i did to manage this issue, is taking advantage of the Schema type (only the type, because using the implementation leads to embedding the whole world in my handler) to extrapolate the GraphQL.
It works very well, and each time i miss something it allows to fail the deploy because of typescript complains.
Code
Don't be too attentive to naming and structuration as it's a 1 hour made solution, it probably require some rework and some abstraction layers to be integrated to the amplify ecosystem.
PS: it requires a path to export
ResolvedModel
which is not exported by default (and it should because it's really useful)Types
Queries defintitions
We probably can compute all the model's queries automatically with a type, but for now i handwrite only those i need.
The client / Query builder
Usage
In my handlers, i use like bellow