feat(cli-2.0): initial draft

[christyjacob4]

preview https://github.com/appwrite/rfc/blob/cli-2.0/018-cli-2.0/018-cli-2.0.md

[Meldiron]

Local testing

Defining testing environments inside appwrte.json looks promising, but will we be able to write multiple tests? I believe all scripts are supposed to return different outputs for different inputs, so we should have an option to write multiple tests. For example

• Register newsletter should return "success" if the email is "[email protected]"
• It should return "error" if the email is "h93grnfb9qewn"
• It should return "error" if the Recaptcha result is incorrect

I can see a solution where instead of "vars" we have "tests" objects like this:

tests: [
  {
      vars: { email: "[email protected]" },
      name: "it should return success with correct email",
      expectedLog: "success"
    },
  {
      vars: { email: "blabla" },
      name: "it should return error with wrong email",
      expectedLog: "error"
    }
]

This is a pretty simple example because we might be looking for more statements such as isNull or isGreaterThan. the expectedLog could follow syntax similar to new database refactoring filters so it could look something like:

tests: [
  {
      vars: { a: 5, b: 8, method: "+" },
      name: "it should equal  5 + 8 = 13",
      expectedLog: "this.result.equalTo(13)" // for output: { result: 13 }
    },
  {
      vars: { a: 5, b: 8, method: "-" },
      name: "it should equal  5 - 8 = -3",
      expectedLog: "this.result.equalTo(-3)" // for output: { result: -3 }
    },
  {
      vars: { a: 2423423, b: 1231412323, method: "*" },
      name: "it should equal  be huge number",
      expectedLog: "this.result.higherThan(999999999)"
    },
   {
      vars: { a: 5, b: 0, method: "/" },
      name: "it should throw error  5 / 0",
      expectedLog: "this.errorMsg.equalTo('Wrong input')" // for output: { result: null, errorMsg: "Wrong input" }
    },
]

.appwriteignore

If we build the application, we only want to deploy the build folder. That would be possible. Problem is, what if we don't build our code and we need to deploy the whole folder? This folder can include .git, .env and other files that may include secret information that we don't want to ship with a build.

Also, if we have a build process in place, I may have node_modules filled with a bunch of development libraries that are not required for production. Can I somehow remove them from deploy to keep it smaller?

Database setup

Since we can set up sites and function, can we also add an option to define collection structure using appwrite CLI? There could be database folder that would hold migrations and seeds, similar to how MySQL does it (Knex for example). Migrations define the scheme of a collection and seeds fill the collection with sample documents. This would also get really related to custom IDs in future, since I probably want to use custom IDs for seed documents (such as Settings document)

[Meldiron]

Function templates

Current RFC includes command:

appwrite init function --functionId="abc" --name="FunctionOne" --runtime=python-3.9

For python, it generates files main.py and requirements.txt. For Node, I would expect package.jsonand app.js.

What if we want to use Typescript? In the end, we are still going to use Node (or Deno) runtime, but the function structure needs to be way different. First of all, we need tsconfig.json and code In src folder. Then, we need a build function. Finally, we need to deploy a specific folder (+ node_modules?).

In my opinion, the init function could get one more parameter:

appwrite init function --functionId="abc" --name="FunctionOne" --runtime=python-3.9 --template=python

There will be multiple templates defined by Appwrite for the most common use cases. This parameter could also support GIT reference, so people can create their own templates. I don't think there is much that the template needs to know. Information such as relative path, function name or runtime can be easily passed using handlebars.

[stnguyen90]

The current CLI is pretty slow because it has to spin up a docker container to execute one command and then tear down.

In addition, passing objects into the CLI is incredibly difficult because of how the data is passed into the container and parsed via the CLI code (Discord conversation)

Any plans on rewriting the CLI to not be a docker image like this?

[stnguyen90]

@christyjacob4, what are the next steps on this?