https://github.com/pagopa/io-eudiw-wpb
This repository contains the code to implement the EUDI Wallet Provider backend (WP).
https://github.com/pagopa/io-eudiw-wpb
eudiw io
Last synced: 10 months ago
JSON representation
This repository contains the code to implement the EUDI Wallet Provider backend (WP).
- Host: GitHub
- URL: https://github.com/pagopa/io-eudiw-wpb
- Owner: pagopa
- Created: 2024-09-16T09:59:17.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-03-03T08:28:07.000Z (11 months ago)
- Last Synced: 2025-03-03T09:28:59.876Z (11 months ago)
- Topics: eudiw, io
- Language: TypeScript
- Homepage:
- Size: 1.96 MB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Codeowners: .github/CODEOWNERS
Awesome Lists containing this project
README
# EUDI Wallet Provider Backend (WP)
This repository contains the code to implement the wallet provider backend (WP), see [section 4.2 of EUDIW Architecture and Reference Framework](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v1.4.1/docs/arf.md#42-reference-architecture).
## Requirements
This project requires specific versions of the following tools. To make sure your development setup matches with production follow the recommended installation methods.
- **Node.js**
Use [nodenv](https://github.com/nodenv/nodenv) to install the [required version](.node-version) of `Node.js`.
```sh
nodenv install
node --version
```
- **Yarn**
Yarn must be installed using [Corepack](https://yarnpkg.com/getting-started/install), included by default in `Node.js`.
```sh
corepack enable
yarn --version
```
- **Terraform**
Use [tfenv](https://github.com/tfutils/tfenv) to install the [required version](.terraform-version) of `terraform`.
```sh
tfenv install
terraform version
```
- **pre-commit**
[Follow the official documentation](https://pre-commit.com/) to install `pre-commit` in your machine.
```sh
pre-commit install
```
## Tasks
Tasks are defined in the `turbo.json` and `package.json` files. To execute a task, just run the command at the project root:
```sh
yarn
```
`Turborepo` will execute the task for all the workspaces that declare the same command in their `package.json` file; it also applies caching policies to the command according to the rules defined in `turbo.json`.
To define a new task:
- add the definition to `turbo.json` under `pipeline`;
- add a script with the same name in `package.json` as `turbo `.
Defined tasks are _lint_, _test_, and _typecheck_.
## Dependencies
> [!IMPORTANT]
> This project uses Yarn Plug'n'Play as installation strategy for dependencies. [Check out](https://yarnpkg.com/features/pnp) the official Yarn documentation to lean about pnp and its difference from the classic `node_modules` approach.
```sh
# install all dependencies for the project
yarn
# install a dependency to a workspace
# (workspace name is the name in the package.json file)
yarn workspace add
yarn workspace add -D
# install a dependency for the monorepo
# (ideally a shared dev dependency)
yarn add -D
```
To add a dependency to a local workspace, manually edit the target workspace's `package.json` file adding the dependency as
```json
"dependencies": {
"my-dependency-workspace": "workspace:*"
}
```
### Yarn SDKS (.yarn/sdks)
Smart IDEs (such as VSCode or IntelliJ) require special configuration for TypeScript to work when using Plug'n'Play installs. That configuration is generated automatically by `yarn` (via `yarn dlx @yarnpkg/sdks vscode vim [other-editor...]`) and commited to `.yarn/sdks`.
## Folder structure
### `/apps`
It contains the applications included in the project.
Each folder is meant to produce a deployable artifact; how and where to deploy it is demanded to a single application.
Each sub-folder is a workspace.
### `/packages`
Packages are reusable TypeScript modules that implement a specific logic of the project. They are meant for sharing implementations across other apps and packages of the same projects, as well as being published in public registries.
Packages that are meant for internal code sharing have `private: true` in their `package.json` file; all the others are meant to be published into the public registry.
Each sub-folder is a workspace.
### `/infra`
It contains the _infrastructure-as-code_ project that defines the resources for the project as well as the executuion environments. Database schemas and migrations are defined here too, in case they are needed.
### `/docs`
Technical documentation about the project. Topics that may be included are architecture overviews, [ADRs](https://adr.github.io/), coding standards, and anything that can be relevant for a developer approaching the project as a contributor or as an auditor.
User documentation doesn't usually go in here. For public packages, it must go in the package's `README` file so that it will also be uploaded to the registry; user-faced documentation websites, when needed by the project, go under the `/apps` folder as they are treated as end-user applications.
## Releases
Releases are handled using [Changeset](https://github.com/changesets/changesets).
Changeset takes care of bumping packages, updating the changelog, and tag the repository accordingly.
#### How it works
- When opening a Pull Request with a change intended to be published, [add a changeset file](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md) to the proposed changes.
- Once the Pull Request is merged, a new Pull Request named `Version Packages` will be automatically opened with all the release changes such as version bumping for each involved app or package and changelog update; if an open `Version Packages` PR already exists, it will be updated and the package versions calculated accordingly (see https://github.com/changesets/changesets/blob/main/docs/decisions.md#how-changesets-are-combined).
Only apps and packages mentioned in the changeset files will be bumped.
- Review the `Version Packages` PR and merge it when ready. Changeset files will be deleted.
- A Release entry is created for each app or package whose version has been bumped.
## Infrastructure as Code
### Folder structure
The IaC template contains the following projects:
#### identity
Handle the identity federation between GitHub and Azure. The identity defines the grants the GitHub Workflows have on the Azure subscription.
Configurations are intended for the pair (environment, region); each configuration is a Terraform project in the folder `infra/identity//`
It's intended to be executed once on a local machine at project initialization.
⚠️ The following edits have to be done to work on the repository:
- Define the project in the right env/region folder.
- Edit `locals.tf` according to the intended configuration.
- Edit `main.tf` with the actual Terraform state file location and name.
```sh
# Substitute env and region with actual values
cd infra/identity//
# Substitute subscription_name with the actual subscription name
az account set --name
terraform init
terraform plan
terraform apply
```
#### repository
Set up the current repository settings.
It's intended to be executed once on a local machine during project initialization. Requirements:
- Generate a Fine-grained Personal Access Token (`PAT`) with the following permissions for this repository:
- Organization:
- Read access to members
- Repository:
- Read access to metadata
- Read and Write access to actions variables, administration, environments, and secrets
- Set `GITHUB_TOKEN` to contain the generated `PAT`
⚠️ The following edits have to be done to work on the repository:
- Edit `locals.tf` according to the intended configuration.
- Edit `main.tf` with the actual Terraform state file location and name.
```sh
cd infra/repository
# Substitute subscription_name with the actual subscription name
az account set --name
terraform init
terraform plan
terraform apply
```
#### resources
Contains the actual resources for the developed applications.
Configurations are intended for the pair (environment, region); each configuration is a Terraform project in the folder `infra/resources//`
⚠️ The following edits have to be done to work on the repository:
- Edit `locals.tf` according to the intended configuration.
- Edit `main.tf` with the actual Terraform state file location and name.
### Workflow automation
The workflow `pr_infra.yaml` is executed on every PR that edits the `infra/resources` folder or the workflow definition itself. It executes a `terraform plan` and comments the PR with the result. If the plan fails, the workflow fails.