Refactor all CloudFormation templates into CDK

Currently there is very little unit testing and zero integration testing. Before release we need to have at minimum all critical paths covered.

First step in this process is defining a list of all the critical paths that we need to have covered, and add them here.

• TODO: add list of critical paths here, with issues created for each

WebUI routing doesn't work for homepage.

Current result:

• url/ loads with empty page (when logged in), redirects to `url/#/
• `url/#/ loads with empty page
• url/#/devices loads fine (after manually editing address)

Expected result:

• url/ loads the homepage
• url/#/ loads the homepage

Bug
It's not possible to build on Linux
When I run ./build.sh s3-for-kickiot v1.0.0 I get:

------------------------------------------------------------------------------
[Dependencies]
jq version: jq-1.6
yarn version: 1.19.2
------------------------------------------------------------------------------

00-cleanup.sh-----------------------------------------------------------------
[Init] Clean old dist and old website dir
rm -rf /*/aws-iot-kickstart/deployment/dist
mkdir -p /*/aws-iot-kickstart/deployment/dist
------------------------------------------------------------------------------

01-prepare-cf.sh--------------------------------------------------------------
[Packing] Cloud formation template

Removing old /*/aws-iot-kickstart/deployment/dist/cf dir (rm -rf /*/aws-iot-kickstart/deployment/dist/cf)
Copying CF folder accross (cp -R /*/aws-iot-kickstart/deployment/../source/cf /*/aws-iot-kickstart/deployment/dist)
Updating code source bucket in templates with s3-for-kickiot and code source version in template with v1.0.0
sed -i '' -e s/%%BUCKET_NAME%%/s3-for-kickiot/g /*/aws-iot-kickstart/deployment/dist/cf/*.yml
sed: can't read : No such file or directory

• Consistent naming of types, querier, mutation, etc (WIP)
• Consistent operation inputs and pagination (WIP)
• Consistent mutation responses (WIP)

Currently there are lots of inconsistencies inapi schema for the above.

Need to update every based on our new GraphQL Conventions

Now that we auto-generate all the model types from Graphql, we need to refactor the angular project to use generated types and remove unused models

• Refactor ALL modules/components to use new generated services
  • Must build sputnik-core-api locally to generate types.
• Delete any models no longer used

NOTE: Some models profile additional functionality and have defaults. Need to make sure we match existing model behavior when refactoring

After major refactor, documentation is out dated. Additionally we decided to move docs for now to github wiki pages.

List is basic list of stuff to do/improve

• General project documentation
• Developer documentation
• Quick start documentation
• "Path to Production" documentation

@teuteuguy Will take a first pass at this and create TODO's with links to issues for others to fill in.

The build framework https://nx.dev/ looks very promising for improving many aspects of this project and enable modularizing the UI components into web-components that could lead to decoupling from angular directly. The key benefit promoted by the project is improved build/test times by targeting only the "affected" code and deep control over the dependencies between packages with the workspace.

Key Benefits:

• Improved build/test times by only targeting "affected" code base
• Tools for building/integrating web-components, angular and react components
• Developer tools and IDE integration

The old version of Sputnik had the concept of "defaults" for defining Device Types, Blueprints, GG functions, etc, but it was tightly coupled to core stack and deployed along with it.

Ideally rather than "defaults" then would just be additional stack to define and deploy the metadata (Device Types, Blueprints, etc) and the lambda code to support them "as code", in an on-going fashion. Rather than an initial single deployment of adding this functionality to the service, it would be seen an codified implementation of the resources to define the specific use case that is used instead of the UI, and is preferred production grade example.

We need to completely re-architect the way we handle this and refactor existing examples into this new system.

Currently "defaults / examples" have been removed from the beta release until we do this refactor.

GraphQL operations need to be cleanup and optimized

• Use fragments for repeated stuff
• Remove extraneous fields
• Delete any unused operations
• Standardize operation naming

We are a security research team and we recently discovered that there is an over-authorization security issue with this project's IoT policy.
The affected file is as following:

1. aws-iot-kickstart/source/cf/sputnik-cognito.yml

After refactoring, subscriptions have tendency to need some extra attention. This issue is here as reminder to go through components and test subscriptions work as expected.

Now that we auto-generate all the apollo angular services, we need to refactor the angular project to use these new service, and to delete any old services no longer in use.

• Update ALL modules/components to use new generated services
  • Must build sputnik-ui-angular-api locally to generate services.
• Delete any services no longer used

Beta release is major refactor of the Sputnik example code to make the project modular, API driven, increase code coverage, and generally make it easy to consume and integrate into actual solutions.

Attention: All versions of Sputnik are to be considered "example" code and are provided "AS IS" under the Amazon Software License.

The Beta Release is being tracking by the Sputnik Beta Release Project and will mark the first official release of the project.

Key Features/Requirements:

• Refactor project to be modular
  • Enable using specific parts of the project rather than "all or nothing"
• Refactor API (Schema First) (WIP)
  • Separate API schema and operations
  • Refactor API schema (WIP) #19
    • Consistent naming of types, querier, mutation, etc (WIP)
    • Consistent operation inputs and pagination (WIP)
    • Consistent mutation responses (WIP)
  • Refactor and optimize API operations #20
  • Use graphql codegen to auto generate everything
    • Generate Types
    • Generate Angular services
    • Generate graphql-request
• Refactor all CloudFormation templates into CDK (WIP) #21
• Refactor / Fix angular web project (WIP)
  • Refactor all services to use new API and generated services (WIP) #22
  • Refactor all models to use generated types (WIP) #23
  • Make sure all subscriptions are wired up and working #24
  • Refactor and upgrade the amplify authentication flow and integration
  • ...
• Improve code coverage for all critical paths #25
  • Infra (WIP)
  • Web
  • Api
  • Lambdas (WIP)
  • ...
• Enable CI/CD deployments and publishing
• Improve development and tooling
  • Consistent ESLint configuration project wide (WIP)
  • Efficient builds and tests
  • ...
• Update documentation #26
  • General project documentation
  • Developer documentation
  • Quick start documentation
  • "Path to Production" documentation
  • ...
• ...

Once all the above have been completed, depending on the level of code coverage and the stability of the project overall, the core contributor team will decide on either release v0 or v1. Anything prior to v1 will not follow Semver and may have breaking changes between minor/patch releases. However from v1 onward, the project will follow strict Semver releases and be considered "stable". Obviously, without comprehensive test coverage this is not possible to maintain, as such will stay in <= v0 until team is confident in ongoing maintainability.