Add Hasura environment variables to make entire schema camelCase

[joserocha3]

Product is awesome so far, excited to get an app into production!

I am wondering if it's possible to set some Hasura environment variables to be able to use camel case naming convention. I can set them in nhost/config.yml for local development, but not via the Nhost console.

It would be great if we could get those variables available in Nhost cloud console, or maybe I am overlooking how to do it?

Cannot set in console:

This works locally:

metadata_directory: metadata
services:
  hasura:
    version: v2.8.3
    environment:
      HASURA_GRAPHQL_EXPERIMENTAL_FEATURES: naming_convention
      HASURA_GRAPHQL_DEFAULT_NAMING_CONVENTION: graphql-default

I can set a graphQL name via the Hasura console, but that only changes the field names, not the entire schema.

Comparison:

[elitan]

This feature is not enabled yet in the Nhost Dashboard, but it's on our roadmap.

[elitan]

I'll keep this issue open until it's possible to change this setting in the Nhost dashboard. It's an important one.

[ttiras]

i need this too and emailed support.

[azlekov]

Hello, any progress on this?

[plmercereau]

We will also need to double-check how hasura-auth and hasura-storage schema would be impacted. From Beep in Discord:

It seems that hasura-auth uses "hasura-default" style type names, like "authUserSecurityKeys_insert_input" so if I switched to "graphql-default" the hasura-auth graphql queries would fail as the new type name would become "AuthUserSecurityKeysInsertInput".

[spakanati]

Any chance this will be enabled anytime soon? Since nhost made the choice to make all the auth and storage schemas, etc. camelcase it makes this feature more important so that public schemas can match instead of being a mixed case schema

[elitan]

We're actively working on a new approach for project configuration, both internally and with the CLI, which will fix this issue.

[gapgag55]

Any updates?

[elitan]

Nothing yet. Our target is to have this available before the end of the year.

The reason it's taking so long is that we're reworking how project configuration will work with Nhost, and there are a lot of moving pieces.

[dohomi]

This would be a great addition. How would an existing schema be affected by the change?

[beepsoft]

Nothing yet. Our target is to have this available before the end of the year.

Maybe this year? 😄 And hopefully earlier?

[elitan]

New target: End of March.

I want this too. camelCase is much better.

[beepsoft]

I know it is not trivial because the graphql operations called from hasura-auth, hasura-storage, etc. must take into account whether camelCase naming convention is in use or not. Practically, you need to have two sets of operations everywhere (one with snake_case and one with camelCase), or must somehow convert from one to the other.

[elitan]

Exactly.

Both Auth [PR] and Storage [no PR needed] are prepared and should work with any naming convention.

We're now working on a new way to manage environment variables across our system and infrastructure. Once in place, adding support for new env vars like this will be trivial.

[joshuadutton]

@elitan Any updates on this? I have some projects that I will be putting into production over the next few weeks, and I would really like to be able to switch the naming convention before I do.

[dbarrosop]

This one fell through the cracks, let me revisit it and see if we can implement it. Issue is that we need to make sure that changing this value doesn't break storage/auth services.

[dbarrosop]

Just did some testing and unfortunately hasura-auth breaks when changing the default mode. this is because while auth is configuring the queries and mutations to be camelCase the parameters are automatically set by hasura in either snake_case or camelCase, depending on the naming convention. In order to support this feature we'd need to fix this issue, for instance, by passing the env var to auth and using one format for the arguments or the other.

As lacking this feature shouldn't be a blocker as users can configure manually the exact naming used by each query or mutation fixing auth is low on our priority list but if someone is willing to help fixing this adding support to configure the parameter should be trivial.

[joshuadutton]

@dbarrosop I'm willing to implement it and send you a PR, I just need some guidance:

• How do I set the env vars when running locally (using nhost up)?
• How do I configure the auth url so it's pointed to my local instance instead of the Docker container?

[joshuadutton]

Both Auth [PR] and Storage [no PR needed] are prepared and should work with any naming convention.

That PR changed auth to access the DB directly and not through GraphQL. When I look at the repo, though, I see that everything is setup to use @graphql-codegen/typescript to generate the Typescript types, including all of the operations with graphql-request. So somebody changed it back.

If you want to move forward with the graphql APIs, you could explicitly name your fields and operations like this: https://hasura.io/docs/latest/schema/postgres/custom-field-names/, but that doesn't cover all of the cases of auto-generation and you would need to abandon some or all of the type generation and have some conditionals to handle the different cases. That's honestly more of a mess.

There are even more options that we could discuss, like accessing auth and files from another Hasura instance through a remote schema, but it looks like you guys already considered these problems and came up with a solution that was already implemented in that PR.

So, which approach do you want to take?

[joshuadutton]

I just did a diff (https://github.com/nhost/hasura-auth/compare/refactor/sql-operations...main), and it looks like most of the support is still there to use pgClient instead of gqlSdk. I could go through and make that change, adding any additional functionality that has been added since the Jan 5th PR. I just want to make sure you support this approach.

[dbarrosop]

That branch was reverted and we are not interested in pursuing that approach. To support different naming conventions what we should probably do instead is just add the ability for hasura-auth to choose between one set of queries/mutations or the other. For instance:

If the naming convention is the default one use:

upsertUsers(on_conflict:....)

If the naming convention is graphql:

upsertUsers(onConflict:....)

/cc @szilarddoro as he may be able to confirm if my approach makes sense or not.

[szilarddoro]

I had to catch up on this, as I was not involved in this discussion earlier. But yes, your approach makes sense to me, David. Although, I'm not sure how the GraphQL codegen would behave if both types of queries were available in the project.

[joshuadutton]

I agree. After thinking about it some more, I think it's best to us Hasura GraphQL APIs, that way we can leverage everything Hasura gives us.

My approach would be this:

• Generate 2 gqlSdk clients, one for each naming convention so the projects would have both TypeScript types.
• Have 2 folders of queries/mutations in the project: one for each naming convention.
• Create a wrapper gqlClient that uses only the default naming convention TypeScript types so that all the rest of the code is consistent.
• If the naming convention is graphql, then the wrapper would convert anything needed, and even get type safety help from TypeScrpt to do so.

[joshuadutton]

As far as codegen goes, whenever some API was changed or added, one would just have to run one codegen configuration pointed to a Hasura instance with one naming convention and then run it again pointed to a Hasura instance with the other naming convention to generate the different types and clients.

[joshuadutton]

@dbarrosop I'm willing to implement it and send you a PR, I just need some guidance:

• How do I set the env vars when running locally (using nhost up)?
• How do I configure the auth url so it's pointed to my local instance instead of the Docker container?

I've figured this out: I can just edit .nhost/docker-compose.yaml and then run docker-compose myself. When I run nhost up, .nhost/docker-compose.yaml is overwritten. Is there a way I can use nhost up with a custom configuration?

[dbarrosop]

You should be able to pass environment variables using the .env file. In any case, to develop this feature you can just use the docker-compose file in the hasura-auth repo, which you can start with make dev-env-up.

[joshuadutton]

Thanks! Yes, I really appreciate the tooling you have added for running everything locally and and the automated tests. https://github.com/nhost/hasura-auth/pull/375

[joshuadutton]

@dbarrosop @szilarddoro any feedback on the PR is appreciated. This feature is important to me, and I'm willing to do the work.

[dbarrosop]

I see you and Szilard are already working on it. Just wanted to say thanks for the PR. Once we have cleared that PR and it's been merged and released I will work on making this configurable on our platform.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[beepsoft]

I haven't followed the recent nhost developments. Is there any progress in this issues?

[dbarrosop]

There is a PR by a member of the community that is WIP

[smeevil]

Would be nice to see this supported

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[joshuadutton]

I stopped using NHost due to issues like these (still using Hasura). I came to check up on the progress of things, and I see that this is being addressed in the new auth service written in Go:

• Blog post: https://nhost.io/blog/auth-to-go
• Repo: https://github.com/nhost/hasura-auth

@dbarrosop What's the status on it? Is the new auth service live? If not, when is it projected to be?

[dbarrosop]

The "new" auth service is live but some endpoints are still being resolved by the old nodejs code. Unfortunately we don't have an ETA on when the migration will be completed.