Workflow

[elitan]

Login

nhost login
> email
> password

save ~/.nhost/nhost.yaml

token: xxxx

---

Nhost init

Go to local project dir.

nhost init

Get list of projects.

Select project.

Will create .nhost/config.yaml with ex:

project_id: <project_id>

Download and applies migrations / metadata

Now remote and local Hasura are in sync.

Nhost dev

1

Make API request to https://customapi.nhost.io/custom/config?id=&token=

Gets settings, ex Postgres/Hausura/HBP version and other settings for docker-compose.yaml.

Creates docker-compose.yaml based on current settings on Nhost production.

2

Pull all dev env vars from Nhost and place in ex .env.development

2

Start docker-compose up -d

3

Start Hasura console using hasura console.

Github

Migrations will be generated. The idea is that users will commit these migrations and let Nhost apply the migrations to production.

The Github integrations might be a bit over-engineered for now, just applying Hasura migrations but the Github integration will make more sense in the future when we support custom api and hosting.

[nunopato]

Looks good, some small notes:

• config.yaml can't be inside .nhost because Hasura needs it at the root of the project alongside migrations

• I think point number 1 in nhost dev can and should be done on nhost init when creating config.yaml

• The same thing for number 2, we are already creating .env.development because of Hasura's webhooks that are specified using ENV vars.

So basically, what we should change is adding nhost login and then nhost init (maybe with a --project-id flag)

[elitan]

1.
Right, about the config.yaml(hasura). We need to handle that too.

I was thinking of a config file specifically for Nhost. Maybe we can name it .nhost/nhost.yaml. We will store the Nhost project id here so nhost dev (and future commands) knows what project it is.

2.
The reason I wanted to place fetching project info in nhost dev was because if a user changes some settings in Nhost that should be reflected next time the user runs nhost dev.

Think about the following case:

• User starts Nhost project.

• User run nhost init.

• User run nhost dev. (then terminate this command)

• User make a change in the Nhost console. Ex upgrade the Hasura version.

• Next time the user runs nhost dev that new hasura version should be used.

However this introduce another issue. Let's say a user is on Hasura v1.2.0 in production and want to upgrade to v1.3.0. The user wants to ofc upgrade the local Hasura version to v1.3.0 first to make sure everything is working. Once everything is working, the user wants to upgrade the Hasura version to v1.3.0 in production. How should this be handled?

One solution would be to introduce some special flag to nhost dev or additional command to handle this. Like nhost pull to pull down all version/settings from Nhost (prod). All settings gets saved in a config file.

Before a user issue nhost dev the user can manually change some configurations in the config file. Ex upgrade Hasura version.

3.
Ah right about the env vars. The issue is that Hasura wont start if not all environment variables are available on startup. This is a bit related to the first (1.) point too.

[nunopato]

1. Do you see a reason for not using the same config.yaml file?

2. Exactly because of the issue you mention (wanting to test different versions locally), I would not always request, with every nhost dev, for the production version being used. I would do that only once, on nhost init. I think we should always encourage local changes first, production next. Also, I could see this being automated (p.e. update hasura version in production) through the CLI.