Version 1.0 Discussion

[bboure]

As mentioned in #91, in order to make the emulator less serverless dependent and more open to other platforms (e.g: amplify), could we discuss a refactoring of this plugin (version 1.0?).

Maybe an approach would be to have this plugin receive a normalized json object containing all the info needed to execute an offline graphQl API. From the top of my head:

• dynamodb config
• lambda functions config
• ... other data source types (pipeline, etc)
• schema
• data sources
• mapping templates
• general configuration (like ports, etc)

Any external platform using the emulator would be responsible for generating the normalized input json and inject it into the emulator's entry script.
For example, this serverless plugin would need to extract all the info from the Serverless instance/serverless.yml and inject it into createServer().

The advantage is that we don't need to support all different platform that are susceptible of using the emulator.

Drawback is that this forces the use of a wrapper for those platform (emulator would not work "out of the box"). We could imagine though, supporting basic wrappers for popular plugins in a different package.

Any thoughts?

[lightsofapollo]

I am strongly in favor. I'd also like to hear what @cbaron (he is back on Monday). Assuming those plugins allow peer dependencies we could potential include them as devDependencies and add some basic level of "does it start" testing to ensure we don't break the consumers.

[marklawlor]

I think for v1.0, this project should look at integrating with Localstack. Its the de facto AWS emulator project and provides already mature DynamoDB and Lambda emulation.

I think this project is trying to do too much in setting up the whole AWS environment and should just focus on being an AppSync emulator.

Localstack already have their own Serverless plugin

[bboure]

Thanks @marklawlor for pointing our localstack. I was not aware it existed.
I'll have a look at it, but it seems like it would make sense to integrate AppSync in it.

[cbaron]

@bboure -- your proposal sounds great. I appreciate the effort you've put into the project.

@marklawlor, @bboure -- agreed we should make it easier to integrate with localstack, but since we've already put in work to spin up a local dynamodb instance with java, we should let the implementor decide if and where to use, point to dynamo respectively.

[bboure]

The biggest challenge to integrating this emulator with localstack would probably be that localstack is written in python, when the emulator is in nodeJs. But a first step would probably be to make possible to have them work together.

I think keeping automatic DynamoDB startup is a good thing for those who want to keep using this emulator as a standalone, but we could definitely consider allowing using an existing instance of DynamoDB, like localstack, instead; or skip it altogether if you are not going to use it at all (eg: if you only use lambda).

That being said, I also think that localstack has a different approach, and probably a different goal than the emulator...

The emulator is clearly made to improve your development productivity, by letting you run your code locally without the need to re-deploy.

Localstack, on the other hand, is more focused on running local version of your project's external dependencies.

In other words, running an AppSync verion in a localstack would make sense if you are working, let's say, on your Front End and want to point to a local version of your API (the API does not change, it just runs). But if you are working on the API itself, the emulator would be the right choice since it point directly to your code and picks up any change.

[marklawlor]

@bboure Take a look at the kinesis emulator. It is simply an extremely small python shell around the NodeJS kinesalite package.

[pianomansam]

What would stop us from only using localstack via docker? I've been using this AppSync emulator within docker and with the dwmkerr/dynamodb docker container, which is a very similar setup to localstack on docker.

[cbaron]

My guess is that a lot of folks use docker to run localstack. That's what we did before migrating to the local java emulator, and I know a few collaborators do the same.

To me, I do not feel the need to make the python implementation of localstack more readily available ( without docker ), but I certainly wouldn't be opposed to this integration -- I would certainly be nicer to remove a dependency on docker in favor of python.

Personally, I would prefer to iterate on the overall architecture of 1.0 as well as the addition of more supported features so that we can try to keep up with aws + serverless.

[pianomansam]

Honestly, wouldn't it be great if we had a single local AWS cloud stack, and had it include AppSync simulation?

[marklawlor]

Just to make it clear, I didn't recommend Localstack as a massive rewrite for this project.

What I would actually like to see are these two goals met:

• A CLI interface (see how the kinesis emulator is started
• Removing the DynamoDB and Lambda emulation in favour of external dependencies.

This would allow the project to scale and be easily used in different ecosystems (eg Localstack)

Say we don't opt for the Localstack approach. I would still love to replace the Lambda emulation with something like docker-lambda (it even has a nice npm package). This is the lambda emulator being used by the Offical AWS SAM Local https://aws.amazon.com/about-aws/whats-new/2017/08/introducing-aws-sam-local-a-cli-tool-to-test-aws-lambda-functions-locally

[lightsofapollo]

I like what @marklawlor is saying here about external deps. I've always seen our lambda support as a hack. I'd like that to go away if nothing else. As appsync has become less dynamodb specific I can see the case for decoupling that as well (less code ftw)

[lightsofapollo]

I've always liked the approach outlined here (leveraging external tools for lambda, etc.). @cbaron and I spoke about this and landed on the following idea:

• move emulator out into it's own repo
• make it very pluggable and not particularly useful on it's own
• rewrite bits of codebase in typescript (i.e. like amplify)
• work on plugins for serverless and amplify.