Introduction

Welcome to MySK's internal onboarding guide for the backend team! Here at the backend team, you will be working primarily with mysk-api, the API service for MySK.

Overview

What is MySK API?

The primary goal of MySK API is to be the only communication layer sitting in between the frontend and the database. Handling all business logic, permissions, conditions and any data constraints.

Technologies

At its core, MySK API is an API service built using the actix-web framework, and follows the REST API architecture which means that...

• Resource-based: Resources are accessible through each entity's respective URIs

• Support for standard HTTP methods: GET, POST, PUT, PATCH, DELETE...

• Stateless communication: Each request from the client contains all the necessary data for the server

Requests and Responses will always be formatted in JSON

🦀 Crabs!

The API is built with the Rust Programming Language, using the actix web framework.

🗃️Database

Our database is powered by Supabase (PostgreSQL) and it's extensive list of features that we totally extensively use 😉

🚀 Deployment

CI/CD is handled by render, which will try to build and deploy changes made to the main branch.

Project Management

Currently, MySK's development is tracked and managed through Linear in a project-based manner using the Agile Methodology. We use Linear to organize

• Issue tracking: Each issue is a "task" assigned to a team member, issues can have their own sub-issues and can block or be blocked by other issues

• Prioritization: Utilizing Linear's prioritization and its points-based estimation, we identify the complexity of tasks in a user's story and manage our sprint effectively

• Roadmaps: Set timelines and milestones which provide an overview of the project's milestones

Team Structure

Current team lead: @Galax028

The backend team consists of 2 main roles. Each will be supervised by the team lead (PR reviews, data validation, etc...)

Backend Developer

Develops and maintains the API and its functionalities. Some members might perform DevOps from time to time.

Data Specialist

Cleans up and normalise every piece of data for uploading to the database.

Q/A Tester

Coming soon...

Planning & Practices

For more details about development, refer to backend/development.

Issues and tasks are delegated in each sprint's "Roadmap & Planning" meeting, which discusses the general direction & structure of the sprint:

1. Endpoint planning

2. Data Modelling

3. Development timeline

4. Migrations & misc.

Branching

We leverage Git and GitHub for hosting, where each development sprint will have its branches, and features within a sprint are developed on separate branches. Upon completion, a feature branch is merged back into the sprint branch using a Pull Request (PR) for review and integration. Once all features for the sprint are merged, the sprint branch is then merged into the main branch

Never merge a feature branch directly into main!

Sprint branch examples

The sprint for "[0.3.0] Clubs" will have these branches:

• feature/0.3.0/club-data-models

• feature/0.3.0/club-registry

These branches will be merged into 0.3.0 first, then after the PR is approved, they will be merged into main.

Commits

Commit messages should adhere to the Conventional Commits Standard. This standard promotes clear & consistent communication with commit messages useful for readability and future references.

$ git commit -S -m "<type>(scope): description"

• <type>: Describes the nature of the change (fix, refactor, chore, build, docs...).

• (scope) optional: Affected parts of the code.

• description: Summary of the commit, which should be written in an imperative verb form.

• body optional: Detailed explanation of the change.

It is recommended to sign your commits before pushing them for better security