What is POKT Gateway Server?

tl;dr Streamline access to POKT Network's decentralized supply network.

The POKT Gateway Server is a comprehensive solution designed to simplify the integration of applications with POKT Network. Its goal is to reduce the complexities associated with directly interfacing with the protocol, making it accessible to a wide range of users, including application developers, existing centralized RPC platforms, and future gateway operators.

Learn more about the vision and overall architecture overview.

• Gateway Operator Quickstart Guide
  • Interested in learning more?
• Docker Image Releases
• Docker Compose
• Minimum Hardware Requirements
• Database Migrations
  • Creating a DB Migration
  • Applying a DB Migration
  • DB Migration helpers
    • Applying Migrations
    • Migrations Rollbacks
• Unit Testing
  • Generating Mocks
  • Running Tests
• Generating DB Queries
• Contributing Guidelines
• Project Structure

Gateway Operator Quickstart Guide

To onboard the gateway server without having to dig deep, you can follow the Quick Onboarding Guide.

Interested in learning more?

We have an abundance of information in the docs section:

1. Gateway Server Overview
2. Gateway Server API Endpoints
3. Gateway Server System Architecture
4. Gateway Server Node Selection
5. POKT Primer
6. POKT's Relay Specification

Docker Image Releases

Every release candidate is published to gateway-server/pkgs/container/pocket-gateway-server.

Docker Compose

There is an all-inclusive docker-compose file available for development docker-compose.yml

Minimum Hardware Requirements

To run a Gateway Server, we recommend the following minimum hardware requirements:

• 1GB of RAM
• 1GB of storage
• 4 vCPUs+

In production, we have observed memory usage increase to 4GB+. The memory footprint will be dependent on the number of app stakes/chains staked and total traffic throughput.

Database Migrations

Creating a DB Migration

Migrations are like version control for your database, allowing your team to define and share the application's database schema definition.

Before running a migration make sure to install the go lang migration cli on your machine. See golang-migrate/migrate/tree/master/cmd/migrate for reference.

./scripts/migration.sh -n {migration_name}

This command will generate a up and down migration in db_migrations

Applying a DB Migration

DB Migrations are applied upon server start, but as well, it can be applied manually through:

./scripts/migration.sh {--down or --up} {number_of_times}

DB Migration helpers

Applying Migrations

• To apply all migrations:

  ./scripts/migration.sh --up

• To apply a specific number of migrations:

  ./scripts/migration.sh --up 2

Migrations Rollbacks

Make sure to provide either the number of migrations to rollback or the --all flag to rollback all migrations.

• To roll back a specific number of migrations:

  ./scripts/migration.sh --down 2

• To roll back all migrations:

  ./scripts/migration.sh --down --all

Unit Testing

Generating Mocks

Install Mockery with

go install github.com/vektra/mockery/[email protected]

You can generate the mock files through:

./scripts/mockgen.sh

By running this command, it will generate the mock files in ./mocks folder.

Reference for mocks can be found here.

Running Tests

Run this command to run tests:

go test -v -count=1  ./...

Generating DB Queries

Gateway server uses PGGen to create autogenerated type-safe queries. Queries are added inside queries.sql and re-generated via ./scripts/querygen.sh.

Contributing Guidelines

1. Create a Github Issue on the feature/issue you're working on.
2. Fork the project
3. Create new branch with git checkout -b "branch_name" where branch name describes the feature.
   • All branches should be based off main
4. Write your code
5. Make sure your code lints with go fmt ./... (This will Lint and Prettify)
6. Commit code to your branch and issue a pull request and wait for at least one review.
   • Always ensure changes are rebased on top of main branch.

Project Structure

A partial high-level view of the code structure (generated)

.
├── cmd # Contains the entry point of the binaries
│   └── gateway_server # HTTP Server for serving requests
├── internal # Shared internal folder for all binaries
├── pkg # Distributable dependencies
└── scripts # Contains scripts for development

Generate via tree -L 2

---

Olshansky's stream of thought here: https://www.notion.so/buildwithgrove/Olshansky-PATH-Journal-dfc92813ca5945ac88035cca97ccbff5?pvs=4