search

little-bear-labs / aws-utils

Apache License 2.0
56 stars 35 forks source link

Version 1.0 Discussion #94

Open bboure opened 5 years ago

bboure commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

pianomansam commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

marklawlor commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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: