Local Workflow

[timsuchanek]

Local Development

We will enable a local development workflow using docker under the hood.
The topic this proposal is shedding light on is how that exactly looks like in the CLI.

Commands

gc local up: Pull & Start a local Graphcool instance
gc local start: Start an already intialized local Graphcool instance
gc local pull: Pull the latest Graphcool version
gc local stop: Stop the currently running local Graphcool instance
gc local reset: Reset the local Project

.graphcoolrc

The .graphcoolrc would get a new "kind" of environment, called local:

default: dev
environments:
  prod: cj7zy085306i50193k7ox16z4
  dev: local

~/.graphcool

{
  "token": "...",
  "local_token": "...",
  "local_host": "localhost:60000"
}

So additionaly to token, there will also be local_token and local_host.
These values all can be overwritten by environment variables:

export GRAPHCOOL_TOKEN=...
export GRAPHCOOL_LOCAL_TOKEN=...
export GRAPHCOOL_LOCAL_HOST=...

There can be one local environment at the same time. When multiple local environments are needed, that orchestration can be achieved with managing the environment variables.

Update:

Add gc local restart command.

Update 2:

As @kbrandwijk suggested, it makes more sense for the local docker environment information to live in the .graphcoolrc file and not the .graphcool file as .graphcool is global and the local docker env information is project related.
With this change the files look as follows:

.graphcoolrc

default: dev
environments:
  prod: cj7zy085306i50193k7ox16z4
  dev:
    token: "..."
    host: "localhost:60000"
    projectId: c27zs08d30ai52683k7mx26a5 # temporary, will be removed soon

~/.graphcool

{
  "token": "..."
}

[schickling]

In general the proposal looks good to me. 👍 Here are a few questions:

gc local reset: Reset the local Project

What does this do exactly (step-by-step)?

export GRAPHCOOL_LOCAL_HOST=...

What does this refer to? What's the purpose of this hostname? What's the underlying network protocol for the intended usage?

[kbrandwijk]

• I feel there might be something counter intuitive about the combination of environment definition and command. If the environment definition is: dev: local then I would expect gc up --env:dev or something etc. Unless the gc local commands get a --env parameter, then it also makes sense.

• Would you be able to create more than one local enviroment?

• Would this local docker environment play a role in automated testing?

• How does deploying to this local environment work? Would you be able to do gc deploy --env dev with dev: local? Would the machine need to be up for that? Or would the docker container contain a reference to the local project folder, so explicitly deploying to your local environment would not be necessary?

• Would you be able to deploy the docker container to a hosting provider, and would that basically be the self-hosted option?

• ~/.graphcool is not project specific. I don't think that these project-specific local environment settings belong there. They should probably go into the project directory.

[timsuchanek]

What does this do exactly (step-by-step)?

We currently have 2 mutations for this:

resetProjectData
resetProjectSchema

They would both be called. We could have 2 more fine-grained versions of the command with --data and --schema.

What does this refer to? What's the purpose of this hostname? What's the underlying network protocol for the intended usage?

This is the deployment endpoint that the CLI needs in order to deploy the project. Currently all endpoints are available on the :60000, we should separate them.

[timsuchanek]

I feel there might be something counter intuitive about the combination of environment definition and command

The idea is, that you can have multiple local environments. So I agree, adding --env to the gc up command is then necessary. We can think about a default here like we do with the current init command.

Would this local docker environment play a role in automated testing?

That's an interesting question, I think it definitely could.

How does deploying to this local environment work?

Yes, the machine needs to be up for that. The CLI should handle it gracefully when deploy is executed without a running docker instance.

Would you be able to deploy the docker container to a hosting provider, and would that basically be the self-hosted option?

Yes, as people can deploy their docker stuff everywhere, this is the first minimal version of the self-hosted option. However, it's built for ease-of-use and not scalability.

~/.graphcool is not project specific. I don't think that these project-specific local environment settings belong there. They should probably go into the project directory.

That's a good point. We have to think about a better solution there.

[danielkcz]

I like this, I just want to add here that it's rather frustrating not even knowing the environment where functions are executed and what language features are supported. Especially that obscure "use latest" flag which is not really explained anywhere what it does. Is it a specific NodeJS version that runs that code?