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

[lohanidamodar]

Some suggestions

[lohanidamodar]

May be some information regarding .appwrite file will be useful as well

[kodumbeats]

Is it possible to have everything in appwrite.json? I think it's a bit confusing to have two different types of config files.

[PineappleIOnic]

Maybe most major configs are done using appwrite.json then .appwrite can be used for API keys and project keys as it'll be hidden by default right? Aslong as we remind users not to commit .appwrite they can share their project with ease

[wess]

Agreeing with @kodumbeats - If we are going to have a .appwrite directory, why not have config.yaml in there (example, how .git is setup) or just have appwrite.yaml

[christyjacob4]

@lohanidamodar .appwrite is actually the folder which some runtimes use to store their dependencies like Python and ruby . Similar to node modules in npm projects

[christyjacob4]

@kodumbeats appwrite.json is a file that is expected to be a part of version control since it will have all the information related to a project like the collections, functions and so on and hence allow them to recreate their project environment . Having secrets in this file doesn't seem like a good idea

[lohanidamodar]

May be we can introduce one more parameter here --template which should be a link to an accessible github repository/branch so that devs can customize to use their own templates as well as our more advance templates, even our demos can be used as template easily using this feature?

[lohanidamodar]

JSON can't have comments 😉

[abnegate]

What do you think about adding a 4th usage for CI environments to deploy some of the projects functions:

appwrite deploy functions --names "My awesome function 💪, FunctionTwo" or
appwrite deploy functions --names "My awesome function 💪" "FunctionTwo"

[wess]

With this and others, I believe we should name space the commands functions deploy (and looking further down, site deploy -y

[abnegate]

For simplicity of use, one of --confirm or --all could be a default

[kodumbeats]

This almost feels like an -i --interactivemode, like an interactive rebase in git?

[wess]

could also follow the common CLI trends with -y instead of a --confirm or --all

[abnegate]

Maybe we could allow runtime to be a language and use the latest version available by default? e.g.:

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

Which would use python-3.9 or whichever is newest at the time

[wess]

Like above: appwrite function init -- This helps when printing help screens too, because you can. order them by the namespaces for readable grouping

[kodumbeats]

Do we need to pick one or the other? I understand that we should think to support OAuth login, but it's not a great CLI experience if a browser is required to login.

[kodumbeats]

Is it possible to validate this ID with the Key validator as a part of the CLI? We could provide real-time feedback even before a request is made.

[kodumbeats]

Does the Fission CLI have any insights to offer?
https://docs.fission.io/docs/usage/function/functions/

[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?

[wess]

I would like to suggest YAML or even TOML, support for them everywhere, easier to read and less prone to type-o frustration with quotes and such. Also... comments.

[wess]

its this to add the Appwrite stack, to setup for functions or just create the config file with the project id? If project, will it also create the project for us on our endpoints?

[stnguyen90]

@christyjacob4, what are the next steps on this?