wiseengineering/crispy

Docs/Links/Infrastructure. Successor to database management tools

crispy

Docs/Links/Infrastructure. Successor to database management tools

Overview

This is a tool to make developers life easier and database setup more reliable.

Architecture

Components

• https://github.com/WiseEngineering/crispy-worker
• https://github.com/WiseEngineering/crispy-web
• https://github.com/WiseEngineering/crispy-api
• https://github.com/WiseEngineering/crispy-cli

They must manage all database operations and be able to execute them in a particular worker.

The main goal for those Components to be responsible for running database operations in worker and give the user the ability to manage it from WEB or by using CLI

How components will interact with each other

crispy's Issues

Describe server <-> library communication

As an example here https://github.com/melnychukvitaliy/mysql-migrate we've used simple https://github.com/db-migrate/node-db-migrate library to manage migration and percona toolkit to run them

We need our interface on how API will communicate with migration libraries (knexjs, db-migrate,..)

Here are the main concepts we need from the library:

• unique migration number
• migration command interface -> should be run in crispy-worker where we have database connection
• library commands to register migrations. For example, publish -> store migration in our database and show in crispy-web

Add crispy logo

Propose CI/CD setup

We have 3 basic components:

• crispy-web
• crispy-api
• crispy-worker

Once they have the initial setup we need docker based environment setup there and CI setup as well
(can be developed with Github Actions)

Propose overall architecture of the tool

• What is the main purpose of the tool
• What components the tool will have?
• How components will interact with each other?

Describe user stories

How users will interact with the tool?

Add interface how components interact with each other

As discussed in the group meeting, there are two possible approaches.

Option 1. Develop own format for migrations; convert existing migrations wroten on Knex, Phinx, etc. into Crispy format; build internal components relying on Crispy format only. This approach will allow localizing a need for 3d party adapters to a single point - conversion of migration files. The downside is that we need to re-implement all the low-level mechanics of DB migrations.

Option 2. Develop a set of components on top of existing migrations and leveraging existing tool's binaries. This requires less overhead to migrate from existing migrations framework to Crispy, but creates maintenance overhead by supporting adapters in multiple junctions of the stack.

See the schema for both options:

We decided to go with the option 1 since it's easier to start with and has a more clear roadmap.

Originally posted by @xTNTx in #5 (comment)

Based on the discussion we had there, we need better docs for crispy Components and how they interact with each other