Add support for project initialization

Description

This is a parent issue. All the other issues linked to it will be having the same properties mentioned. The goal here is to enable users to create a new project in any of their preferred stacks or programming languages. We would enable creating this directly via our CLI. The usage would look something like this:

ks init --name <project_name> --type <project_type>

The options does the following:

name: Specifies the name of the new project.
type: This is an enum type value. This defines the type of project the users want to create. Possible values could be node, maven, rust, react, etc.

Example - Running the following command,

ks init --name my-api --type nestjs

will create a new project named my-api in the current working directory, which is a nestjs project.

Architecture

Initialization

We aim to keep things simple. Here is the approach we take to implement this feature:

We will use existing starter initializers to create the projects. For example, we will use nest-cli to create the nestjs project we demoed in the previous step.
We will then add project specific code to set up the initial code for live updates.
We create a keyshade.toml file that will be used by the SDK to read properties. This will contain the following:
- profile_name: The name of the profile from the system local config. Specifying this alone will allow the users to not specify any other of the below configs.
- api_token: The API key to access the keyshade API
- private_key_file: The location of the private key file on the device. Not required if private_key is specified.
- private_key: The plain text private key. Not required if private_key_file is specified. private_key will be given more preference than private_key_file.
- project: The name of the project the code will refer to
- environment: The name of the environment the SDK will be fetching its configs from.

Auto generated code

The purpose of this code is to do the following things:

Use the CLI to fetch schema for the project+environment. This will contain an enum or map type value. The pair will be config name - config id. So for example, if a project API has an environment dev that contains variables PORT, BASE_URL and secrets JWT_SECRET and TOKEN, the inference will look something like this in the schema file for a typescript node based project:

File name: api.schema.ts
```
export const Variable: any = {
  PORT: 3000,
  BASE_URL: 'http://localhost:3000'
}

export const Secret: any = {
  JWT_SECRET: 'supersecurekey',
  TOKEN: 'sensitive_data_here'
}
```
The schema will be fetched every time the application is run. Any changes made to the config names will be reflected in here. This is necessary because we want the application to keep using updated code. Not only that, if any entry of this file is updated, all code occurrences will be updated as well. For example, consider TOKEN is changed to API_TOKEN. Then, all code occurrences of TOKEN should change to API_TOKEN as well.
After the fetching is done, the generated code will be responsible for auto fetching the secrets and variables using the ID, decrypt the data using private_key, and set them in the environmental variable of the runtime. For example, we would be setting PORT=3000 in the environment of the runtime
In the code, all references made using ks.resolve(schema.Variable.PORT) will refer to PORT=3000 that we have set earlier.
The code will automatically create a webhook that can be configured using the keyshade.toml's webhook_url key. The default will be {BASE_URL}/keyshade/live-updates. This webhook will allow for dynamic changes to be applied to the code. Any data that gets sent to this - which will be new versions created or roll backed - will be set to the environmental variable. The code should ensure that only keyshade's official API can make the requests. This setting can be configured via authorized_host in keyshade.toml. The default will be api.keyshade.xyz.
Lastly, upon initialization, the code will call the {authorized_host}/register-application endpoint with the following data: project, environment, webhook_url. This will tell the API to send updates whenever the configurations are changed.

Code structure

We want to use the following class structure:

InitAction: This class will create the keyshade.toml file, and later, delegate the call to its abstract and initializeSchema(), initializeProject() and initializeCode() functions.
<Language>InitAction: This class will implement the initializeSchema() function and initialize the schema for the particular programming language. For example, JavaInitAction. This class will inherit InitAction and implement initializeSchema(), and delegate the call to initializeProject() and initializeCode().
<Stack>InitAction: This will implement the initializeCode() and initializeProject() commands.

Here is the example code:

trait InitAction {
    fn initialize(&self) {
        println!("Initializing project...");
        self.initialize_config();
        self.initialize_schema();
        self.initialize_project();
        self.initialize_code();
        println!("Project initialized successfully!");
    }

    fn initialize_config(&self) {
        println!("keyshade.toml generated");
    }

    fn initialize_schema(&self);
    fn initialize_project(&self);
    fn initialize_code(&self);
}

trait JavaInitAction: InitAction {
    fn initialize_schema(&self) {
        println!("Java schema generated");
    }
}

trait NodeJSInitAction: InitAction {
    fn initialize_schema(&self) {
        println!("NodeJS schema generated");
    }
}

struct NestJSInitAction;

impl NodeJSInitAction for NestJSInitAction {
    fn initialize_project(&self) {
        println!("NestJS project created");
    }

    fn initialize_code(&self) {
        println!("NestJS boilerplate code added");
    }
}

struct MavenInitAction;

impl JavaInitAction for MavenInitAction {
    fn initialize_project(&self) {
        println!("Maven project created");
    }

    fn initialize_code(&self) {
        println!("Maven boilerplate code added");
    }
}

fn main() {
    let action: &dyn InitAction = &MavenInitAction;
    action.initialize();
}

Supported frameworks and languages

This section contains the issues related to maintaining and expanding the functionality of this feature.

keyshade-xyz / cli