yearn / yearn-caching-api

🍕 Lightweight Rest API shim for yearn's SDK

Yearn API

Small SDK shim + Metadata endpoint for Yearn

This codebase hosts non user specific data provided by the SDK to increase the speed of providing this data as well as reducing the number of web3 calls

Setting up GitHub Actions

The service can be deployed using GitHub actions. The service is deployed on the infrastructure described here.

To set up GitHub actions, you will first need to create a AWS User with the proper IAM policy to deploy the service.

Here is the minimal policy you need:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RegisterTaskDefinition",
            "Effect": "Allow",
            "Action": [
                "ecs:RegisterTaskDefinition",
                "ecs:DescribeTaskDefinition"
            ],
            "Resource": "*"
        },
        {
            "Sid": "PassRolesInTaskDefinition",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::<aws account id>:role/<yearn api task definition execution role>",
                "arn:aws:iam::<aws account id>:role/<yearn api task definition task role>"
            ]
        },
        {
            "Sid": "DeployService",
            "Effect": "Allow",
            "Action": [
                "ecs:UpdateService",
                "ecs:DescribeServices"
            ],
            "Resource": [
                "arn:aws:ecs:*:<aws account id>:service/yearn-api-cluster/YearnAPIService"
            ]
        },
        {
            "Sid": "GetAuthorizationToken",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowPush",
            "Effect": "Allow",
            "Action": [
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "ecr:BatchCheckLayerAvailability",
                "ecr:PutImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload"
            ],
            "Resource": "arn:aws:ecr:us-east-1:<aws account id>:repository/yearn-api-repo"
        }
    ]
}

Replace the following placeholders:

• <aws account id> - Your aws account id
• <yearn api task definition execution role> - The name of the task definition execution role. This should be automatically created when your create the infrastructure
• <yearn api task definition task role> - The name of the task definition task role. This should be automatically created when you create the infrastructure

Create a new AWS user and attach the newly created policy to that user.

Create a new GitHub environment in the repo called production. Add the following secrets in the new environment (use the credentials of the new user you just created):

1. AWS_ACCESS_KEY_ID
2. AWS_SECRET_ACCESS_KEY

IMPORTANT

Optionally, setup environment protection rules to control who is able to deploy a new version of the app.

Deploying a new version

To deploy, run the build and deploy workflow from the actions page.

Starting

$ make

Stopping

$ make down

Production deployment

$ PROD=true make

yearn-caching-api's Issues

New icons are not used

Steps to reproduce

• Run the api
• A new vault is endorsed, an icon is added to https://github.com/yearn/yearn-assets e.g. in this PR yearn/yearn-assets#174
• Go to localhost:3000/v1/chains/250/vaults/get
• Data for the new vault is present but the displayIcon field is ""
• No icon is displayed on the website

This is because icons are loaded at initialization of the sdk, and not updated thereafter

To fix
Find someway to recognize when a vault has been added and refresh the data from the assets service (https://github.com/yearn/yearn-sdk/blob/master/src/services/assets.ts). Perhaps this could be a scheduled job

Error when filtering strategy metadata based on address

http://localhost:3000/v1/chains/1/strategies/metadata/get?addresses=0xa258C4606Ca8206D8aA700cE2143D7db854D168c

gives an error cannot read properties of undefined (reading 'toLowerCase')

the correct functionality is to only return the vaults filtered by the addresses inputted in the request

[INF-13-37] test issue gh > linear (please delete me)

HELLO I LOVE YOU PLEASE DELETE ME

[INF-18-40] Fix root route test

Currently when we run tests, the test fails, here are the reasons.

• response is not accurate
• teardown is causing timeouts, need to be able to handle this properly

[INF-10-35] Test issue linear > GH

[INF-19-41] Is this a circular reference?

I was under the impression that
https://api.yearn.finance/v1/chains/1/vaults/all

pointed to this endpoint: https://github.com/yearn/yearn-api/blob/633fe7f69ee3eaea7a3ccebd771a91bc901c09e4/routes/v1/chains/:chainId/vaults/index.mjs#L85

but this endpoint then calls another api under the env variable process.env.API_MIGRATION_URL. What is the value of this process.env.API_MIGRATION_URL? In the repo itself, process.env.API_MIGRATION_URL points to api.yearn.finance https://github.com/yearn/yearn-api/blob/5934ea55ba145977956104cbde68202ea28aed3d/.env.example#L6

It just seems like these api calls just go in a circle and I am having a hard time understanding where the https://api.yearn.finance/v1/chains/1/vaults/all gets its data.

Thanks for any help

Observability: Expose prometheus metrics for yearn-api

Background

There isn't a lot of visibility into the current health on this service. Before we can start monitoring the health of this service, we need to be able to generate metrics on how well the service is performing.

Metrics of interest might be:
Latency, number of requests, number of responses with a particular status code, etc....

To enable monitoring and alerting we need to do 3 things:

1. Generate relevant metrics
2. Export generated metrics into an observability tool
3. Set up monitoring and alerts when metrics exhibit abnormal behaviour

In this issue, we will focus on 1.

Goal

Integrate fastify-metrics into this service. The library will generate request metrics for this service.

Success Criteria

Visiting the /metrics endpoint on the service displays request metrics for the service. The metrics should capture 2xx, 3xx, 4xx and 5xx responses.

Capture any errors and exceptions with Sentry

Background

Sentry is an error tracking platform. It can be used to collect, track and diagnose unexpected errors.

All critical services should have sentry integration.

Goal

1. Capture all fastify errors with Sentry
2. Capture all errors in bree jobs with Sentry

Remove iron bank related code and endpoints

Iron bank is no longer supported by Yearn, all code, endpoints, and jobs related to it should be removed

[INF-11-36] Test issue GH > Linear

please delete me if you see this.