Use Case

[danielblignaut]

Hi @ziggy6792 ,

just wondering what your use case is for this repo? Also, why use bash for you cognito commands over using the js AWS sdk?

[ziggy6792]

Oh hi @danielblignaut

Thanks for getting in touch again.

My Use Case

My use case is at the moment really just a serverless starter project which showcases the following;

• Cognito Auth - With Facebook login
• GraphQL api on lambda - Using typegraphql (I am not using Appsync because I have bad expiernces with it in my previous project, I hate vtl and it seems mocking locally is a huge amount of effort)
• Data stored in dynamo db - dynamodb-data-mapper pairs very nicely with typegraphql I have found
• Authenticated and unauthenticated access to the api - so that I can have guest user access and also user roles
• Pipelines for deploying frontend and backend changes

My ultimate goal is to use this setup for a booking system website (users could use my site to create appointments with a service provider).

Actually I do have all of the above setup now. Getting the authentication and pipelines working took me the longest time.

Some Feedback

I would love to get your opinion on some of my changes (or if you think I destroyed your beautiful project :) ). But I would have to do some cleanup first and do a small write up of the changes I made and why. Is that something you would be interested in? I can have it ready this week. There are a few things that I have added to the repo that I think you might be interested in;

• The typegraphql backend. It might be interesting to see a non Appsync approach
• I have setup absolute and alias import paths in all of the packages so no more ../../../../../ugly/import/paths
• I made some changes to the local lambda server so that changes to common packages are rebuilt immediately and automatically when you change the source code. In your original repo you would have to rebuild a common package manually (e.g: common-lambda-lib) to see the the changes in the local lambda-server.

Bash for you cognito commands

Please ignore that. I have some stuff I copied in from an old project when I really didn't know what I was doing. I want to redo all that stuff but some of it is still useful and redoing it is not a high priority.

Please let me know if you would have time to give me some feedback and I will clean it up and write some stuff up for you as I said.

Thanks again,

Simon

[danielblignaut]

Hey @ziggy6792 ,

sure. I'm currently under pressure on another project that uses this library but I've actually extended it dramatically. Once I've got time to refactor and remove close sourced code, I'll update.

I've written a library that does the following:

• specify your typescript models, graphql API models and dynamodb models in one package and enforce type safety. I write my GraphQL models programatically so can validate them against typescript models and dynamodb models. I've been using this for typescript dynamodb but it's not the greatest ( https://shiftcode.gitbook.io/dynamo-easy/ )
• You attach what graphql endpoints you want to create (CREATE, READ, UPDATE, LIST or custom defined ones) with some config options and it automatically scaffolds out your appsync resolvers and graphql API endpoints. There is a package in AWS Amplify project called "graphql-mapping-template" or something like that. Let's you write appsync VTL templates in plain JS. I plan to eventually create a local appsync mock using ideally the final appsync vtl but otherwise basically taking my "graphql-mapping-template" js code and instead of boiling down to apache VTL, just boiling it down to mock Javascript code that can function locally.
• For each microservice you want to run, there are some common CDK constructs with some common configs - I.e. each service has a appsync graphql service, dynamodb table, AWS lambda function, dynamodb streams, aws step functions
• I also added then a gateway service that loads all graphql resolvers in my sub-services and stitches it into 1 common appsync graphql service that uses http resolvers under the hood to query the sub-services.

I've also then done the following with my local setup:

• lambda server (you've seen this)
• use local aws step functions service that points to my lambda service
• localstack for most other service implementations locally (dynamoDb, s3, cognito, eventbridge). No real local solution for appsync or API gateway yet.
• Most importantly, I've written code that understands how to create a test user for testing Appsync API's programatically with a cognito user and it also understands how to login and switch roles via code between each of my AWS accounts for remote tests.
• I also figured out how to locally render CDK templates, then cache them, so that in between tests I dont have to re-render my entire CDK app every time as jest runs a new env for every test suite... this really speeds up testing and a big final thing I want to add to this: When you cache the cdk template, you can convert it into a cloudformation template. I want to then traverse that cloudformation template and re-create all the infrastructure locally where possible.

I believe there's scope to eventually build this into a bigger open source project. My main beliefs here is constructing an "opinionated" CDK infrastructure project for people looking to:

• use dynamodb
• use appsync / graphql
• use step functions
• use eventbrdige
• use typescript
• build microservice oriented projects

So anyone looking to do that can have a pre-defined set of CDK tools at their disposal. If you're interested in helping me do this, we can try figure out how to start, what we think is key and roadmap it.

[ziggy6792]

Hey @danielblignaut

Sorry for the late reply. It is party season here in Singapore :)

I just have some comments on your first point

• specify your typescript models, GraphQL API models and dynamodb models in one package and enforce type safety. I write my GraphQL models programatically so can validate them against typescript models and dynamodb models. I've been using this for typescript dynamodb but it's not the greatest ( https://shiftcode.gitbook.io/dynamo-easy/ ).

This sounds like a code-first Appsync approach right? Are you using this? For typescript dynamodb I have been using dynamodb-data-mapper- it's maybe more limited than the library you are are using but the api is very nice and it works well with TypeGraphQL (which I am using instead of Appsync). Basically I watched this tutorial series on TypeGraphQL and thought it looked really cool and solved all the issues I was having when I was using Appsync. I copied the setup from the tutorial but I use dynamodb-data-mapper as my Object Document Mapper instead.

What I love about my setup; TypeGraphQL has this concept of higher order resolvers meaning that you still write your simple CRUD stuff very quickly and succinctly It is a code first approach which means doing the complex stuff beyond CRUD is an easy extension Because it is not tied to AWS it is very easy to run locally just using express (and mocking the dynamodb locally using cdk local and local stack). Also this means porting my solution off AWS should be pretty painless (just have to switch out my dynamodb Object Document Mapper to another one) No more VTL! The one drawback is that I am not sure how or if I could get GraphQL subscriptions working. But thats not really important to me.

The rest of the stuff you mentioned sounds really really cool. And I would love to see your progress as you go. However I am sorry to say I am not keen to help. The main reason being with my work + the project I am working on I don't have enough time. The other issue is that I am very reluctant to work with Appsync now after my previous experiences and I prefer to work on an approach that it more cloud agnostic.

Good luck and please keep me posted on your progress I can do the same for you :) Thanks again for all your help.