Workflow

[nhost]

Workflow

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