kudos-ink/base-api

kudos BASE api

Prerequisites: Install Diesel CLI locally to use make file nigration

HOW TO RUN:

$ make db-up
$ make db-migrate
$ make run

Local Development

Docker

Pre-requisites

This Dockerfile requires BuildKit and buildx. BuildKit is an improved backend to replace the legacy builder. BuildKit is the default builder for users on Docker Desktop, and Docker Engine as of version 23.0.

Enable it by setting:

export DOCKER_BUILDKIT=1

Build

To build the image, use:

docker build . -t kudos-api

Run

docker run -e DATABASE_URL=... -e HOST=... -e PORT=... kudos-api

Docker-compose

Run

It builds the image if it's the first time, otherwise, it uses the latest built image.

docker-compose up

Build and run

docker-compose up --build

Test

Unit tests

Run the command:

make test

DB tests

These tests needs a real postgres DB running. You can start a new one using docker-compose up db and then running the tests:

make test-db

Note: the tests will delete some tables before running. Use a dummy DB!

Deployment

Workflow

This repository is connected to render.com and will trigger a new deployment to production when a new commit arrives in main branch.

base-api's Issues

Support paginated request for `get_contributions`

Support query ordering for `get_contributions`

Add deploy workflow

• Setup shuttle.rs to deploy the API
• Automate the deployment using a tag
• Get a free db

Support query filters for `get_contributions`

Rename `db` mods into `services`

As suggested here in #6

Document endpoints

We can use a swagger like utoipa based on OpenAPI: https://github.com/juhaku/utoipa/tree/master/examples/todo-warp

Protect DB writes with auth

Using something compatible with GitHub OAuth

Generic CRUD pattern trait for DB services

Instead of having multiple DB services traits for each route, we should implement a generic one following CRUD pattern. For example:

#[async_trait]
pub trait DBService<T, K>: Send + Sync + Clone + 'static 
where
    T: Send + Sync + 'static, 
    K: Send + Sync + 'static,
{
    async fn get_all(&self) -> Result<Vec<T>, reject::Rejection>;
    async fn get_by_id(&self, id: i64) -> Result<Option<T>, reject::Rejection>;
    async fn create(&self, item: K) -> Result<T, reject::Rejection>;
    async fn update(&self, id: i64, item: K) -> Result<T, reject::Rejection>;
    async fn remove(&self, id: i64) -> Result<(), reject::Rejection>;
}

Contributions database schema

It involves:

• users (auth and profile)
• repository (owner, name, languages, etc)
• issues (status, labels, description, etc)

RESTful API

Develop a RESTful API in Rust with PostgreSQL as the database, dockerized for ease of development and deployment.

API Development

• Written in Rust, utilizing Warp as the web framework
• Route-based file structure to ensure modularity and maintainability
• Implements CRUD operations

At the moment we can focus only on one identity: contributions
The goal is to trigger a create contribution using a Github webhook on issue opening.

File structure

api/
│
├── src/
│   ├── main.rs                # Entry point for the API application
│   ├── contributions/
│   │   ├── handlers.rs        # Request handlers for 'contributions'
│   │   ├── models.rs          # Data models for 'contributions'
│   │   └── routes.rs          # Route definitions for 'contributions'
│   ├── db/
│   │   ├── mod.rs
│   │   └── connection.rs
│   └── utils/
│       └── mod.rs
│
├── tests/                     # Integration tests
│   └── contribution_integration_tests.rs
│
├── Dockerfile
├── docker-compose.yml
├── Cargo.toml
└── Cargo.lock

Change