# support-service-lambdas [![Codacy Badge](https://api.codacy.com/project/badge/Grade/df83c14325bc4c29aeae7e529f49f8a9)](https://app.codacy.com/app/johnduffell/support-service-lambdas?utm_source=github.com&utm_medium=referral&utm_content=guardian/support-service-lambdas&utm_campaign=badger)

This is the reader revenue lambda API/orchestration layer. It is made up of lambdas, defined in the /handlers directory and libraries defined in the /libs directory. Code in the repo is mostly Scala but for new lambdas prefer to use Typescript for the following reasons:

• There is a wider pool of experienced Typescript developers both within the Guardian and outside making it easier to find devs to work on the codebase
• It enables us to share code between server side applications, client side applications and infrastructure definitions (CDK)
• Cold start times for Typescript lambdas are typically faster than for Scala ones

Please keep all the various README in this project up to date, and improve them! There should be one in each project and anywhere else you think it would help.

Getting Started - Typescript

Install Node.js. The Node version is required is encoded in the .nvmrc file at the root of the repo. We recommend using a Node version manager such as fnm.

Once Node is installed and you're using the correct version, install the correct package manager (currently pnpm) with corepack (from the root of the repo):

$ corepack enable

Then install dependencies (again, from the root of the repo):

$ pnpm install

Each lambda is a separate pnpm workspace which allows us to define common settings and dependencies for all projects, add dependencies between projects build all projects at once and generally facilitates the management of a monorepo

Linting rules (.eslint.config.mjs), formatting rules (.prettierrc) and Typescript configuration (tsconfig.json) are all defined at the root of the repository and use standard Guardian configuration where available.

These can also be overridden at a per workspace level, for instance each lambda should override the rootdir setting through a local tsconfig.json file as follows:

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "rootDir": "./src"
  }
}

Dependencies can also be managed either at the root workspace level or in individual lambdas. To add dependencies to a specific sub-project you can use pnpm filtering:

pnpm --filter discount-api add dayjs

or simply run the add command in the root directory of the subproject

pnpm add dayjs

To add dependencies to the workspace so that they are available to all project you can use:

pnpm --workspace-root add dayjs

however this should only be used for dependencies which really are necessary for all sub-projects.

Filtering can also be used to run builds or any other command on a particular sub-project, for instance:

pnpm --filter discount-api package

Linting can be run for all workspaces:

pnpm lint

or a specific workspace:

pnpm --filter alarms-handler lint

Auto-fixing linting errors only works when a workspace is specified:

pnpm --filter alarms-handler lint --fix

Getting Started - Scala

1. Open the project in Intellij with Scala plugin installed
2. Open Intellij / Settings / Build, Execution, Deployment / Build Tools / sbt
3. Turn on sbt shell for project loading and compilation.
4. (optional for better scala 3 support) switch the scala plugin to "nightly" or "early access" rather than Release
5. Go into "handlers" and find the relevant lambda(s), and check (or add) their Getting Started section

Running all Integration tests

These tests do not (yet!) run automatically.

You can run the tests that hit external services by running sbt effectsTest:test. This would need suitable AWS credentials to get hold of the config. You can tag your integration new tests with taggedAs EffectsTest. This ignores them from the standard sbt test.

NOTE: You may notice that IntelliJ doesn't compile the effects tests on-the-fly (as it does with source files) you can re-enable this behaviour by commenting out the contents of the Seq(...) at the end of the val testSettings assignent in the top-level build.sbt . This is also means you can run them with the IntelliJ debugger :)

Testing post deployment to CODE/PROD

The PROD health checks are called by blazemeter every 5 minutes.

Misc

Generating CloudFormation templates:

See the docs for setup and running guides.

Adding a new lambda:

See this doc

Scala dependency tree

run sbt dependencyTree

Finding unused code and dependencies (knip)

knip analyses the TypeScript workspaces to report unused files, exports, types and dependencies, plus dependencies that are used but not declared. It is a useful way to keep the lambdas and shared modules lean.

Run it from the root of the repo (using the Node version in .nvmrc):

pnpm knip

knip is configured in knip.ts. A few things are worth knowing about how it is set up for this monorepo:

• Shared modules are imported through the @modules/* TypeScript path alias rather than by package name, so knip cannot link those imports back to the workspace:* dependency. The config therefore ignores internal workspace packages (they are also required by buildcheck for pnpm --filter <project>...). External (third party) dependencies are still checked.
• Handler entry points are src/index.ts (api-gateway lambdas) and src/handlers/*.ts (step function lambdas); runManual/* scripts are also treated as entry points.
• knip exits with a non-zero status when it finds issues, so it can be wired into CI once the existing findings have been triaged.

Because every lambda/module package.json is a managed file (see buildcheck/README.md), fix any unused-dependency findings by editing buildcheck/data/build.ts and running pnpm snapshot:update — do not edit the generated package.json files directly.

External documentation:

• knip docs: https://knip.dev
• knip configuration reference: https://knip.dev/reference/configuration