Backpack

Appearance

Project structure ​

How to organize your project, depends on your use case and architecture.

Single npm workspace ​

A typical Backpack project currently has a single package.json, representing a single npm workspace.

Its directory structure may look like this:

  • app/ - contains the (TypeScript) source files of your serverless app
  • cdk/ - contains your infrastructure code for AWS CDK
    • bin/ - contains the entry point(s) for AWS CDK
    • config/ - environment-specific configuration for your infrastructure
    • lib/ - contains (TypeScript) source files for your infrastructure-as-code
  • docs/ - any system documentation for your project
  • integration-tests/ - any integration tests

Using npm workspaces (experimental) ​

You can also choose for multiple separate npm workspaces. For example:

  • Infrastructure code (CDK)
  • Backend (REST API)
  • Frontend (UI)

This pattern is useful when adopting a mono-repo approach as it allows for more fine-grained dependency management at the package level.

Feedback requested!

We are considering adopting npm workspaces into Backpack. If you have any feedback regarding this, we are happy to hear your thoughts.

Hexagonal design ​

Hexagonal architecture separates your app’s core domain logic from the outside world using ports (interfaces) and adapters (implementations). It makes your domain independent, so things like databases or REST endpoints can be swapped without touching business logic.

Pros:

  • Easy to test and maintain
  • Swappable external parts (e.g., APIs, DBs)
  • Clean separation of concerns

Cons:

  • More boilerplate and mapping needed
  • Can be overkill for small apps

More information on this architecture, and how to apply it on AWS Lambda: