Basics of Creating a Framework

Here's a roadmap and architecture considerations that we will be following in building a backend framework or library:

1. Define the Objectives and Scope (DONE)

Clearly define the goals and objectives of your backend framework or library.
Determine the scope of the project and the specific problems it should solve.

Empower bootstrap backend without vendor lock-in, low cost of scaling and with its own Content Management UI.

2. Research and Understand Existing Solutions (DONE)

Explore existing backend frameworks and libraries to gain insights into their architecture and design choices.
Identify the strengths and weaknesses of these solutions to inform your own design decisions

Solutions	Description
Firebase	Costly at scale and does not come with it’s own admin dashboard (for non-developers)
Butter CMS	SaaS only, closed source and no on-premise
Contentful CMS	SaaS only, closed source and no on-premise
Supabase	Open Source technology but does not come with its own admin dashboard (for non-developers). SaaS or on-premise
Strapi	Strapi is a CMS we use a lot for our backend, the admin dashboard can be decoupled from the backend server which we can then scale with Kubernetes or Docker. But downside is that the entirety of the backend is built on Node JS, Koa JS. The memory usage and CPU usage is high and can be costly to scale due to Node JS. Changing of runtime to other runtimes such as Bun.sh or the recently released WinterJS is also not possible due to Strapi being tightly coupled to Node JS. React JS is used for its frontend.
Directus	Similar to Strapi, but with Vue JS for its frontend. Been around longer than Strapi.
WordPress	Powerful mature CMS powering 43.2% of all websites. Built with PHP and requires a lot of tooling for optimisation and caching to scale which can be costly. Can be too convoluted for scaling with the backend. Constantly targeted by “Script Kiddies” or Web Crawlers attempting to attack unpatched vulnerabilities of older sites. Too many plugins will significantly slow down the performance of the site. Can be headless CMS as well
PocketBase	Built with Golang and comes with a simple admin dashboard, but is not meant to be a fully-fledged CMS like Strapi and Directus. It only supports SQLite. Does not come with a plugin system to embed additional features and UI to the admin dashboard. Focuses on being more of a pure backend rather than a CMS.

3. Design the Architecture:

Define the core components and features your backend framework or library will provide.
Consider the separation of concerns, modularity, and extensibility of your architecture.
Identify the key modules, such as routing, request handling, database interaction, authentication, etc.

Everything will be a module. Database module, authentication module, authorisation module.

Authentication

Either Sessions or JWT tokens

Both have pros and cons

Database

SQLite as a module