Concepts

The @aws/nx-plugin is an Nx plugin that provides a toolkit for simplifying the process of building and deploying full-stack applications on AWS. It provides developers with pre-configured templates for both application and IaC code, significantly reducing the time spent on setup and configuration. The plugin handles the complexity of AWS service integration while maintaining flexibility for customization.

Users simplify pick and choose which components they want from the list of available Generators, provide any configuration options and have the @aws/nx-plugin generate the required starter code. Several generators exist within this toolkit which can create APIs, websites, infrastructure and even do more sophistacted things like integrated a frontend to a backend (including updating existing files via AST transforms!) with type-safe clients.

Built on top of Nx

Nx is a smart build framework that excels at managing complex polyglot projects through two core features: an intelligent build system and code generators.

The build system uses advanced caching and dependency graph analysis to optimize task execution. It only rebuilds what’s necessary based on code changes, significantly reducing build times. Tasks can run in parallel, with Nx automatically determining the optimal execution order based on project dependencies. This makes operations like testing, linting, and building highly efficient, especially in larger codebases.

Generators serve as automated scaffolding tools that create consistent code structures across projects. They can produce anything from individual components to complete applications, following predefined templates and patterns. Teams can customize these generators to match their specific requirements and coding standards.

Together, these features make Nx particularly effective for managing monorepos and ensuring consistent development practices across teams while maintaining high development velocity.

Generators

All components available in this plugin as implemented as Generators which enable the automation of repetitive tasks and allow consistent scaffolding of both new and existing projects.

Generators can be invoked via the Nx CLI or the Nx Console IDE plugin.

Open for modification

All code generated is your code, meaning it is free to be edited as you see fit. This drastically simplifies the developer experience as if you don’t like something in the generated code, you are free to modify it.

Minimal dependencies

The @aws/nx-plugin strives to keep the number of dependencies to a minimum and as such the global requirements for getting started boil down to what generators you invoke.

As an example, any Typescript based generator will only require Node to be installed. For Python based projects, UV is the only requirement.

Note

UV was chosen as the Python package and project manager for a few reasons including: - Single tool which acts as a drop-in replacement for pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, and more - 10-100x faster than pip - Native workspace/monorepo support

Single version policy

The default monorepo setup uses a single version policy for both Node and Python based project.

This means that all projects within your monorepo will be using the same version of dependencies by default, reducing issues related to packages in the same monorepo running into version mismatch issues.

From a Node perspective this means a single lockfile at the root with a single node_modules containing all dependencies. If you need to add a new dependency, you do it in the root package.json.

From a Python perspective, this means a single .venv in the root of the monorepo with all dependencies installed into it. Each Python project however will have it’s own pyproject.toml, but the versions of those dependencies are managed by the uv workspace and subsequently written out to the uv.lock file in the root.

Type safety

The @aws/nx-plugin employs type-safety to simplify the developer experience via IDE completions, whilst also eliminating runtime errors which would only occur in a non type-safe implementation. As such, all components that are vended will be type-safe by default.