API

Information

We will provide official documentation for the API, which will be based on the frameworks Supabase, Strapi, and Appwrite. This documentation will serve as the primary reference for our multi-tenant API, encompassing all general reference points. However, to facilitate the onboarding process for new developers, we aim to expand upon the existing reference material, enhancing clarity and accessibility. This approach will ensure that developers can efficiently understand and utilize the API, promoting a smoother integration experience.

Note

• Official documentation will be provided for the API, which is written in Rust, Python and the database is in SQL.
• This documentation will hold all the general reference points for the multi-tenet API, however we would need to expand upon the reference material and try to make it easier to onboard new developers.

Auth

• Auth Journal

  • For the core of the API, we will use JWT as the key in between the $User and $API.

• React JSX

  • The first mod will be the core auth system between the client $User and server $API, which includes the register and login. While we build it out, we will include generic defensive components into the foundation, then re-visit and apply external security, such as limits and firewalls (some may operate outside of the API).
    • Cookie Storage (of the JWT)
      • Cookie - token - will store the client $User JWT.
      • Cookie - user - will store the client $User data.
      • Library: react-cookie will be used to help maintain the cookies.

• For the Appwrite JWT, we will be holding it inside of a session store from Nanostores, at least as of right now.

API Keys

API keys serve as unique identifiers, allowing our application to communicate seamlessly with our servers. Rather than asking for a user’s password— which can pose security risks— these keys authenticate requests by proving that the application making the request is authorized. Think of them as special passwords generated specifically for the software, ensuring secure data exchange while keeping user credentials confidential. By utilizing API keys, we prioritize both the user’s privacy and the integrity of our platform.

v0

The current method of storage has a couple risks that we need to migrate, including the way the data is being encrypted within the storage of the database.

API Install Introduction

In the dynamic world of software, where even a moment’s downtime can make or break user trust, managing the API installation process is paramount. P resently, our journey starts at Proxmox, winds through qEMU, and culminates in Docker Swarm. From there, Portainer takes the baton to deploy the image. While most of our front-end instances proudly wear the labels of applications or static pages, there are those intriguing outliers - the edge cases where we might stumble upon SSR or hybrid applications. Let’s dive deeper into this fascinating setup.

The current API installation process needs to be migrated but it currently sits as this:

• Proxmox -> qEMU -> Docker Swarm
• Portainer -> Deploy Image

With all front-end instances being either applications or static pages. There might be a couple edge cases where we have SSR or hybrids applications.

v1

For v1, we would like you to look into the Appwrite documentation

v0

The following information below is for installing the older API, which was just a MariaDB cluster with Strapi.

Locker

Locker Information

The locker will serve as a client-side storage for variables and data points that we do not need to hit the main server for!

The current locker that we are using as of August 12th, 2023 is below, but if we need to extend it out further, we shall.

Locker

The locker, aka a client-side storage, that allows web applications to store data directly in a user’s browser, offering speed and offline accessibility. However, to ensure data integrity and security, locking mechanisms can be implemented, restricting unwanted or concurrent modifications. Think of it as a personal vault in your browser, where the combination is known only to trusted sources

export type kbveLocker = {
	username: string;
	phone: string;
	last: string;
	uuid: string;
	avatar: string;
	github: string;
	instagram: string;
	email: string;
	theme: 'dark' | 'light' | 'auto';
};

Locker Storage

For the management of the locker storage on the client-side, we will be using nanostores!. There is an option to extend AES encryption ontop of the stored values but that will be something that we can implement in the start of the next year.

Uptime Notes

Uptime is the heartbeat of any API, indicating its reliability and performance in real-time.

Ensuring consistent availability is crucial, as even minor downtimes can impact user experience and trust.

Diving deep into the world of API uptime, this documentation equips you with the tools to vigilantly monitor and enhance your service’s responsiveness.

• 

The current uptime badge is handled by ChecklyHQ, however we could build out our own uptime management software down the line. This would be an interesting test case for the NodePy, having it automatically do test cases every hour. I will make an issue ticket when I feel like it would be time to set this up.

Goals

In the vast cosmos of software, APIs are the Jedi Masters, bridging the divide between different software galaxies. Like the Force in Star Wars, they bind and intertwine disparate systems, ensuring harmony in the digital universe. By sculpting robust and intuitive APIs, we’re not just coding; we’re forging lightsabers for the next generation of developers, ensuring the saga continues seamlessly. The API is an unique construct that extends outside of the normal universe, the net that holds the sky.