Replacing Yoga with Amplify Appsync Simulator (or having both as an option)

[tomschut]

Since using yoga the way it's currently used causes some issues regarding [fragments])(#112) and typenames I've done a small test to see if amplify appsync simulator would work better.

I've used this article as a base, and found that both issues get resolved. Since I'm working in the playground and not directly in the package it's easiest to post the example code here.

import { readFileSync } from 'fs'
import { join } from 'path'
import type { AmplifyAppSyncSimulatorConfig, AppSyncSimulatorPipelineResolverConfig, AppSyncSimulatorUnitResolverConfig } from 'amplify-appsync-simulator'
import {
    AmplifyAppSyncSimulator,
    AmplifyAppSyncSimulatorAuthenticationType,
    RESOLVER_KIND,
} from 'amplify-appsync-simulator'
import { load } from 'js-yaml'
import { argv } from '../packages/server/src'
import { main as prismaAppSyncHandler } from './handler'
import { readVTL } from './vtl/readVTL'

class AppSyncSimulator {
    httpPort: number
    wssPort: number

    constructor(httpPort: number, wssPort: number) {
        this.httpPort = httpPort
        this.wssPort = wssPort
    }

    async start() {
        const schema = readFileSync(join(process.cwd(), argv.flags.schema), { encoding: 'utf-8' })
        const simulatorConfig: AmplifyAppSyncSimulatorConfig = {
            appSync: {
                defaultAuthenticationType: {
                    authenticationType: AmplifyAppSyncSimulatorAuthenticationType.AMAZON_COGNITO_USER_POOLS,
                    cognitoUserPoolConfig: {},
                },
                name: 'api-local',
                additionalAuthenticationProviders: [],
            },
            schema: { content: schema },
            mappingTemplates: [
                {
                    path: 'lambdaRequestMappingTemplate.vtl',
                    content: readVTL('lambdaRequestMappingTemplate.vtl'),
                },
                {
                    path: 'lambdaResponseMappingTemplate.vtl',
                    content: readVTL('lambdaResponseMappingTemplate.vtl'),
                },
            ],
            dataSources: [
                {
                    type: 'AWS_LAMBDA',
                    name: 'prisma-appsync',
                    invoke: prismaAppSyncHandler,
                },
            ],
            resolvers: createPrismaAppSyncResolvers(),
        }
        const amplifySimulator = new AmplifyAppSyncSimulator({
            port: this.httpPort,
            wsPort: this.wssPort,
        })
        await amplifySimulator.start()
        await amplifySimulator.init(simulatorConfig)
    }
}

const httpPort = 4000
const wsPort = 4001
const simulator = new AppSyncSimulator(httpPort, wsPort)
simulator.start().then(() => {
    // eslint-disable-next-line no-console
    console.log(`🚀 App Sync Simulator started at http://localhost:${httpPort}/graphql`)
})

export interface PrismaAppsyncResolverConfig {
    typeName: string
    fieldName: string
    dataSource: string
    requestMappingTemplate: string
    responseMappingTemplate: string
}

function createPrismaAppSyncResolvers(): (AppSyncSimulatorPipelineResolverConfig | AppSyncSimulatorUnitResolverConfig)[] {
    // read resolvers from yaml
    const resolvers = load(readFileSync(join(process.cwd(), 'prisma/generated/prisma-appsync/resolvers.yaml'), 'utf8')) //this should be an arg flag

    return resolvers.map((r: PrismaAppsyncResolverConfig) => ({
        ...r,
        dataSourceName: r.dataSource,
        kind: RESOLVER_KIND.UNIT,
        requestMappingTemplateLocation: 'lambdaRequestMappingTemplate.vtl',
        responseMappingTemplateLocation: 'lambdaResponseMappingTemplate.vtl',
    }))
}

the vtl files can be found here

However, I do get an error about the aws date,"message": "DateTime cannot be serialized from a non string, non numeric or non Date type {}", which already didn't work in the dev branch in which i'm testing.

I think using this setup would not only resolve both issues, but also open a way to run multiple lambda's as resolvers if needed in the future.

So let me know if this is something that could be done. I think I can help in implementing it

[maoosi]

@tomschut That's very interesting! I didn't know about the amplify-appsync-simulator package, which is why I ended up creating my own function to emulate it. Will have a deeper look at it as soon as I have some availability.

[maoosi]

I think so yes, no need for having both as long as amplify-appsync-simulator provides an IDE and can deliver on the same underlying requirements for headers and CORS settings.

[tomschut]

could you elaborate on the requirements for headers/cors? I can't seem to find them in the docs just yet.. I also can't find anything on headers in the amplify config btw.

[maoosi]

@tomschut sure! So right now, you can call the createServer function with the bellow parameters:

createServer({
  // GraphQL Schema path (default is `prisma/generated/prisma-appsync/schema.gql`)
  schema,

  // Lambda handler (default is `handler.ts`)
  lambdaHandler,

  // Server port (default is `4000`)
  port,

  // Watchers config (to hard reload the server)
  watchers,

  // HTTP Headers passed inside the Lambda Event
  headers,

  // default query when launching the GraphQL IDE
  defaultQuery,

  // customise the default Yoga Server options (see example below)
  yogaServerOptions
})

Here is an example how to use CORS with the above options:

createServer({
    yogaServerOptions: {
        cors: {
            origin: 'http://localhost:4000',
            credentials: true,
            allowedHeaders: ['X-Custom-Header'],
            methods: ['POST']
        }
        /* ...other args */
    }
})

And here is a concrete example of someone wanting to use the headers to improve the local dev environment:
#139

With the future implementation, we still want to be able to use the above parameters - except for yogaServerOptions that will have to be replaced/adapted based on what's possible.

[tomschut]

I'm afraid I can't find any way to introduce extra headers in the amplify implementation. I've found something about it here but am unsure if this is a solution, or even the same problem.

In the meantime I have a branch with the non-breaking addition of amplify appsync as an option. To test this the server.ts would have to look like

import { join } from 'path'
import { readFileSync } from 'fs'
import { load } from 'js-yaml'
import type { PrismaAppsyncResolverConfig } from '../packages/server/src'
import { argv_appsync_simulator, createAmplifyAppsyncServer } from '../packages/server/src'

(async () => {
    const schema = readFileSync(join(process.cwd(), argv_appsync_simulator.flags.schema), { encoding: 'utf-8' })
    const resolvers = load(readFileSync(join(process.cwd(), argv_appsync_simulator.flags.resolvers), 'utf8')) as PrismaAppsyncResolverConfig[]
    const lambdaHandler = await import(join(process.cwd(), argv_appsync_simulator.flags.handler))

    const httpPort = argv_appsync_simulator.flags.httpPort
    // const wsPort = argv_appsync_simulator.flags.wsPort

    createAmplifyAppsyncServer(
        httpPort,
        lambdaHandler,
        schema,
        resolvers,
    )
})()

one does need to add js-yaml as a dev dependency.

Let me know if it's ok to create a PR for this. I believe the extra options amplify introduces could make it a workable dev server, even though headers are still an issue.

As for watchers, I've not introduced them into the amplify server, I'm not sure what they add to it

[maoosi]

The watchers are currently used for 2 things:

• Modifying your schema.prisma will automatically run npx prisma generate.
• When detecting a change on schema.gql (after npx prisma generate), the local dev server will automatically reload.

Yes, please open a PR and we can go from there. Thanks!