@opeslabs/sdk v1.33.0-development107

OPES SDK

https://www.npmjs.com/package/@opeslabs/sdk

Getting started

0. As this is intended to be an open-source project, we will want to first fork the original project that can be found here. Make sure you are added to the Github organization.
1. Fork the project and clone it on your machine
2. Set the remote upstream of the fork to point to the opeslabs repository
3. Install the dependencies by running yarn install

Building

1. In order to build the project, we have to run yarn build in order to generate all the transpiled files

Branching & Pull Requests

Current workflow is as follows:

0. Make sure your main branch is up to date with the upstream
1. Create a new feature-branch. This is where you will do most of the work regarding a feature. A common naming convention would be feat-#23/framer, where #23 is the issue in the organization's project.
2. Commits will be linted and checked with commitizen, so it's easier when you want to commit some changes to run npx cz
3. When you consider the branch to be done, create a pull request into the upstream/main branch from opeslabs and ask for reviewers
4. After the PR is approved by 1 or more peers, you can merge it into the main
5. After, you will want to sync your local main with the upstream main branch from the original opeslabs repository

Local development

Since this is an SDK, it does not do much on its own unless it's imported in another project.

If you want to take the latest version that's available on npm, you can simply run yarn add @opeslabs/sdk and then import whatever methods you need

If you want to test locally functionality that you've written inside the local SDK, we first need to:

0. create a feature-branch
1. implement your changes
2. run yarn build in order to compile all files that will be used (a /lib folder will be generated)
3. run npm i . -g in order to install this local version globally on your machine
4. Then, in the project you want to test out the functionality, run npm link @opeslabs/sdk in order to link it to the globally installed package
5. After you're done testing the integration, run npm unlink @opeslabs/sdk in order to remove the reference and then go back to using the NPM version by installing it with: yarn add @opeslabs/sdk

Using the SDK

Fetching the monsters list

1. Login to you Metamask
2. Filter for the NFTs in the Monster collection and map over the tokenId attribute (use Alchemy SDK or something similar)
3. The above array of numbers will be passed as payload along with the env in the following API call from the SDK

import { getWaitingListGatekeepersByIds } from '@opeslabs/sdk/lib/services/waitinglist';

...

const response = await getWaitingListGatekeepersByIds({
  ids: nftIds,
  env: 'dev',
});

Fetching the monster's details

1. nftId is equivalent to tokenId from the metamask account collection

import { getGatekeeperDetails } from '@opeslabs/sdk/lib/services/waitinglist';

...

const apiMonsterNFT = await getGatekeeperDetails({
  gatekeeperId: nftId,
  env: 'dev',
});

Deployment

When the feature is ready and you've tested locally that it's working (check above), we want to deploy it to npm

0. First we make sure we're on the feature branch
1. Bump the package version
2. Stage & commit the files & push it to the branch
3. Open a PR into the upstream main
4. Ask for reviews and once they're approved merge the PR
5. Publish the package by running npm --access public publish
6. Sync your forked main with the upstream main
7. Create a release tag in Github with the version from the package.json

Deploying

0. Log in to npm
1. Perform necessary changes
2. Run yarn build
3. Increase version in package.json
4. Stage & commit & push into your fork's main and then merge it
5. Open PR into upstream and ask for reviews
6. Merge PR
7. Run npm --access public publish
8. Create a release tag in Github with the version from the package.json

Perfomance

We're using k6.io to run performance testing, stress testing, load testing etc...

Installation

Make sure you have installed k6 on your machine with brew install k6.

We won't use the Graphana/Cloud runtime from their end right now, we will currently run the tests locally on our machines.

Tests are writter in the /test/performance folder.

Note:

Unfortunately you cannot import the query/mutation from the **/mutations folders directly, so you will just have to paste the string and pass it to the buildRequest wrapper. K6 is written in go so it doesn't understand TS or node modules (like graphql-request or gql)

Terminology:

• vus: virtual users
• duration: how long the stress test should run (you can swap this with stages if you need ramping up/down etc)
• thresholds - threhsholds of interest like avg response time, rate of failure in percentage etc..

Running a performance test

In the terminal run:

k6 run test/performance/waitlist/getTopics.ts