I needed to do some research to find out how to see the console.log from your functions in the terminal. Maybe it's helpful to add this to the docs. Not sure if there is a more elegant way though ;) I found the necessary command here: https://youtu.be/1V6KKbRaLhM?t=645
This file has diverged from the respective doc [page](https://docs.nhost.io/platform/quickstarts/vue#configure-nhost-with-vue)
Maybe the docs should be updated instead to match the current file, in any case, i think will be nice to fix this and avoid confusion & friction to new comers trying the vue integration out.
When I was searching for the "redirectTo" param I didn't find anything in the docs, maybe it was my fault but I've missed this.
Sorry if this is duplicated.
The client URL is set to `window.location.origin`, so it can rewrite redirection urls that are
passed on to authenticaion methods. However, `clientUrl` is set to `''` when running on the server
side. This fix then avoid raising an error when trying to rewrite `redirectTo` on non-browser
environment, and forces `useProviderLink` to be rendered on the client side.
Clarifying where nhost client instance should be made for ease of following and understanding the documentation. I think ultimately it should follow the steps shown subsequently.
Update the guide based on Johan's feedback + add a new section at the end to show how to use the GraphQL API to fetch user data + reflect changes from the provided template.
As discussed with Johan. The React template for this guide has also been edited to remove Tailwind CSS and use CSS modules instead.
You can find this template here: https://github.com/gdangelo/cra-template-quickstart-nhost. Please make sure to move it to the Nhost Github repository and publish it to npm.
As discussed with Johan. The Next.js template for this guide has also been edited to remove Tailwind CSS and use CSS modules instead.
You can find this template here: https://github.com/gdangelo/nhost-quickstart-nextjs. Please make sure to move it to the Nhost Github repository.
I ran into an issue where I couldn't sign up users because the auth service wasn't able to connect to mailhog.
That caused the auth service to not send an email and not respond to the HTTP request.
fixes#499
I'm wondering if anyone else had this issue. If I'm the only one then maybe this PR is obsolete.
- We use [pnpm](https://pnpm.io/) as a package manager to speed up development and builds, and as a basis for our monorepo. You need to make sure it's installed on your machine. There are [several ways to install it](https://pnpm.io/installation), but the easiest way is with `npm`:
```sh
$ npm install -g pnpm
```
- Our tests and examples use the Nhost CLI, to run the backend services locally. You can follow the installation instructions in [our documentation](https://docs.nhost.io/get-started/cli-workflow/install-cli).
## Get started
### Installation
First, clone this repository:
```sh
git clone https://github.com/nhost/nhost
```
Then, install the dependencies with `pnpm`:
```sh
$ cd nhost
$ pnpm install
```
### Development
Although package references are correctly updated on the fly for TypeScript, example projects won't
see the changes because they are depending on the build output. To fix this, you can run packages
in development mode.
Running packages in development mode is as simple as:
```sh
$ pnpm dev
```
Our packages are linked together using [PNPM's workspace](https://pnpm.io/workspaces) feature. Vite automatically detects changes in the dependencies and rebuilds everything, so that the changes are immediately reflected in the other packages.
### Use examples
Examples are a great way to test your changes in practice. Make sure you've `pnpm dev` running in your terminal and then run an example.
Let's follow the instructions to run [react-apollo example](https://github.com/nhost/nhost/blob/main/examples/react-apollo/README.md).
## Run the documentation website locally
The easier way to contribute to our documentation is to go to the `docs` folder and follow the [instructions to start local development](https://github.com/nhost/nhost/blob/main/docs/README.md):
```sh
$ cd docs
# not necessary if you've already done this step somewhere in the repository
$ pnpm install
$ pnpm start
```
## Run test suites
### Unit tests
You can run the unit tests with the following command from the repository root:
```sh
$ pnpm test
```
### End-to-end tests
Each package that defines end-to-end tests embeds their own Nhost configuration, that will be automatically when running the tests. As a result, you must make sure you are not running the Nhost CLI before running the tests.
You can run the e2e tests with the following command from the repository root:
```sh
$ pnpm e2e
```
## Changesets
If you've made changes to the packages, you must describe those changes so that they can be reflected in the next release.
We use [changesets](https://github.com/changesets/changesets) to support our versioning and release workflows. When you submit a pull request, a bot checks if some changesets are present, and if not, it directs you to add them.
The most comprehensive way to add a changeset is to run the following command in the repository root:
```sh
$ pnpm changeset
```
This will create a file in the `.changeset` directory. You can edit it to give more details about the change you just made.
You can take a look at the changeset documentation: [How to add a changeset](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md).
## Committing changes
You'll notice that `git commit` takes a few seconds to run. We set a commit hook that scans the changes in the code, automatically generates documentation from the inline [TSDoc](https://tsdoc.org/) annotations, and adds these generated documentation files to the commit. They automatically update the [reference documentation](https://docs.nhost.io/reference).
- Serverless Functions: Node.js (JavaScript and TypeScript)
- [Nhost CLI](https://docs.nhost.io/reference/cli) for local development
@@ -47,19 +47,19 @@ Nhost consists of open source software:
Visit [https://docs.nhost.io](http://docs.nhost.io) for the complete documentation.
# How to get started
# Get Started
### Option 1: One-click deployment with Nhost (recommended)
## Option 1: Nhost Hosted Platform
1.Create [Nhost account](https://app.nhost.io) (you can use GitHub to sign up)
2. Create Nhost app
3. Done!
1.Sign in to [Nhost](https://app.nhost.io).
2. Create Nhost app.
3. Done.
### Option 2: Self-hosting
## Option 2: Self-hosting
Since Nhost is 100% open source, you can self-host the whole Nhost stack. Check out the example [docker-compose file](https://github.com/nhost/nhost/tree/main/examples/docker-compose) to self-host Nhost.
## Sign in a user and make your first GraphQL query
## Sign In and Make a Graphql Request
Install the `@nhost/nhost-js` package and start build your app:
@@ -67,7 +67,8 @@ Install the `@nhost/nhost-js` package and start build your app:
<img style="width: 260px; height: 56px" src="https://runacap.com/wp-content/uploads/2022/06/ROSS_badge_black_Q1_2022.svg" alt="ROSS Index - Fastest Growing Open-Source Startups in Q1 2022 | Runa Capital" width="260" height="56" />
</a>
### How to contribute
Here are some ways of contributing to making Nhost better:
- **[Try out Nhost](https://docs.nhost.io/get-started/quick-start)**, and think of ways to make the service better. Let us know here on GitHub.
- Join our [Discord](https://discord.com/invite/9V7Qb2U) and connect with other members to share and learn from.
- Send a pull request to any of our [open source repositories](https://github.com/nhost) on Github. Check our [contribution guide](https://github.com/nhost/nhost/blob/main/CONTRIBUTING.md) for more details about how to contribute. We're looking forward to your contribution!
- Send a pull request to any of our [open source repositories](https://github.com/nhost) on Github. Check our [contribution guide](https://github.com/nhost/nhost/blob/main/CONTRIBUTING.md) and our [developers guide](https://github.com/nhost/nhost/blob/main/DEVELOPERS.md) for more details about how to contribute. We're looking forward to your contribution!
### Contributors
@@ -141,13 +147,6 @@ Here are some ways of contributing to making Nhost better:
You defined `select` permissions for the `public` role in the previous section. You will now add `insert` and `create` permissions for authenticated users to secure your app's GraphQL API with authentication.
> Nhost's authentication service lets you deliver frictionless registration and login experiences to your users. We support most social providers and different methods such as email & password and passwordless (magic link).
---
## Insert a test user
Manually create a user by going to your app's **Users** tab (top menu) and clicking on **Add User**.

You will now use that newly created user to make authenticated requests to the API.
---
## Authenticate and query data
Add the following code to sign in the new user and request the list of todos again:
```js
import{NhostClient}from'@nhost/nhost-js';
constnhost=newNhostClient({
backendUrl:'https://[app-subdomain].nhost.run',
})(async()=>{
// Sign in user
constsignInResponse=awaitnhost.auth.signIn({
email:'joe@example.com',
password:'securepassword',
});
// Handle sign-in error
if(signInResponse.error){
throwsignInResponse.error;
}
// Get todos
consttodos=awaitnhost.graphql.request(`
query {
todos {
id
created_at
name
is_completed
}
}
`);
console.log(JSON.stringify(todos.data,null,2));
})();
```
Why is the return value `null`? Because when making GraphQL requests as an authenticated user, the `user` role is assumed.
> For authenticated requests, there is always the option to override the default `user` role with any other valid role.
---
## Permissions for users
### Remove permissions for the public role
We won't use the `public` role anymore, so let's remove all permission for that role.

Now we'll add permissions for the `user` role.
> All logged-in users have the `user` role.
### Insert permission
First, we'll set the **Insert permission**.
A user can only insert `name` because all other columns will be set automatically. More specifically, `user_id` is set to the user's id making the request (`x-hasura-user-id`) and is configured in the `Column presets` section. See the image below.
For **Select permission**, set a **custom check** so users can only select todos where `user_id` is the same as their user id. In other words: users are only allowed to select their own todos. See the image below.
In the previous tutorials, we tested various parts of Nhost, such as:
- Database
- GraphQL API
- Permission
- JavaScript SDK
- Authentication
All changes we did to our database and API happened directly in production of our Nhost app.
It's not ideal for making changes in production because you might break things, which will affect all users of your app.
Instead, it's recommended to make changes and test your app locally before deploying those changes to production.
To do changes locally, we need to have a complete Nhost app running locally, which the Nhost CLI does.
The Nhost CLI matches your production application in a local environment, this way you can make changes and test your code before deploying your changes to production.
## Recommended workflow with Nhost
1. Develop locally using the Nhost CLI.
2. Push changes to GitHub.
3. Nhost automatically applies changes to production.
When we created the `customers` table there was also a migration created automatically. The migration was created at under `nhost/migrations/default`.
```bash
$ ls -la nhost/migrations/default
total 0
drwxr-xr-x 3 eli staff 96 Feb 7 16:19 .
drwxr-xr-x 3 eli staff 96 Feb 7 16:19 ..
drwxr-xr-x 4 eli staff 128 Feb 7 16:19 1644247179684_create_table_public_customers
```
This database migration has only been applied locally, meaning, you created the `customers` table locally but it does not (yet) exists in production.
To apply the local change to production we need to commit the changes and push it to GitHub. Nhost will then automatically pick up the change in the repository and apply the changes.
:::tip
You can commit and push files in another terminal while still having `nhost dev` running.
:::
```bash
git add -A
git commit -m "Initialized Nhost and added a customers table"
git push
```
Head over to the **Deployments** tab in the **Nhost console** to see the deployment.

Once the deployment finishes the `customers` table is created in production.

We've now completed the recommended workflow with Nhost:
In the previous section, we only created a new table; `customers`. Using the CLI you can also do changes to other parts of your backend.
There are three things the CLI and the GitHub integration track and applies to production:
1. Database migrations
2. Hasura Metadata
3. Serverless Functions
For this section, let's do one change to the Hasura metadata and create one serverless function
### Hasura Metadata
We'll add permissions to the `users` table, making sure users can only see their own data. For this, go to the `auth` schema and click on the `users` table. then click on **Permissions** and enter a new role **user** and create a new **select** permission for that role**.**
We can now test the function locally. Locally, the backend URL is `http://localhost:1337`. Functions are under `/v1/functions`. And every function's path and filename becomes an API endpoint.
This means our function `functions/time.ts` is at `http://localhost:1337/v1/functions/time`.
Let's use curl to test our new function:
```bash
curl http://localhost:1337/v1/functions/time
Hello undefined! It's now: Sun, 06 Feb 2022 17:44:45 GMT
Let's create a simple todo-app using Nhost. In a todo-app, a user should be able to create list items for their account (CRUD) and not have anyone else see them (permissions).
To implement this todo-app with Nhost, we'll briefly cover these topics:
- Creating a new app on Nhost
- Defining a database schema
- Inserting data
- Setting permissions
- Querying data via the GraphQL API
By the end of this quick-start, you will better understand what Nhost is and what it does for you.
---
## Log in to Nhost
Go to [app.nhost.io](https://app.nhost.io) and sign up for a new account if you don't have one already.
---
## Create app
Press the **"New App"** button on the console's home page. Choose a name and pick the region closest to your users.
You'll be all set with the Default Workspace and the Free plan for now.

Creating a new app takes around 20 seconds or so. During this time, Nhost sets up your app's entire backend and infrastructure.
Once the setup completes, you'll automatically see the app dashboard, and you're ready to define your app's database schema.
In the previous section, you used the Hasura Console to fetch a list of todos. Now, you will write a small JavaScript client to interact and retrieve todos from your Nhost app.
### Frontend frameworks
Nhost is framework-agnostic and works with any frontend you might build. You can also connect to Nhost from your server-side if you wish.
In this guide, we'll keep the example simple. We're not using a frontend framework. In a real-life scenario, you'd probably build a frontend client with a framework such as React, Vue, Svelte or React Native.
---
## Setup
> Make sure you have [Node.js](https://nodejs.org) and [npm](https://docs.npmjs.com/getting-started) installed.
Create a new folder called `nhost-todos`, and initialize a new JavaScript app there:
Using npm package manager
```bash
npm init -y
```
or
Using Yarn package manager
```bash
yarn init -y
```
> You might have to edit the `package.json` file and add/change the `type` object to `module` (`"type": "module"`).
Install Nhost JavaScript SDK:
Using npm package manager
```bash
npm install @nhost/nhost-js
```
or
Using Yarn package manager
```bash
yarn add @nhost/nhost-js
```
---
## Initialize Nhost
In the new directory, create a file called `index.js`.
Enter the following code into this file. It will initialize a new `NhostClient` that will interact with your backend:
```js
import{NhostClient}from'@nhost/nhost-js';
constnhost=newNhostClient({
backendUrl:'https://[app-subdomain].nhost.run',// replace this with the backend URL of your app
});
console.log(nhost.graphql.getUrl());
```
Run the code in your terminal. You should see your app's GraphQL endpoint URL:
```bash
➜ node index.js
https://[app-subdomain].nhost.run/v1/graphql
```
### Query todos
If you now add the following GraphQL query to the client, let's see what happens when you run the updated version:
```js
import{NhostClient}from'@nhost/nhost-js';
constnhost=newNhostClient({
backendUrl:'https://[app-subdomain].nhost.run',
})(async()=>{
// nhost.graphql.request returns a promise, so we use await here
In the previous section, you could fetch the todos because the **admin** role is enabled by default when using Hasura Console. When building your applications, you want to define permissions using **roles** that your users can assume when making requests.
Hasura supports role-based access control. You create rules for each role, table, and operation (select, insert, update and delete) that can check dynamic session variables, like user ID.
## Unauthenticated users
Use the `public` role in permissions when you want some data to be accessed by anyone without being signed in. The `public` role is the default role in all unauthenticated requests.
Generally speaking, the `public` role should not have insert, update or delete permissions defined.
### Setting `public` permissions
In Hasura Console, go to the **Data** tab, click on the **todos** table, then click **Permissions**. Add a new role called `public` and click on **select**. The permission options for the select operation show up below.
1. Nhost sets the `public` role for every unauthenticated GraphQL request.
2. You explicitly defined permissions for the `public` role.
It is essential to understand that Hasura has an **allow nothing by default** policy to ensure that only roles and permissions you define explicitly have access to the GraphQL API.
To implement an app for managing a todo list, let's ensure we have database tables for storing todos and users.
---
## Open Hasura Console
Hasura generates real-time GraphQL APIs, but it also provides a web console for manipulating the schema and data of your database.
Go to the **Data** tab on your app's dashboard and select **Open Hasura**. Remember to copy the admin secret.
The Hasura Console of your app's dedicated Hasura instance will open in a new tab. You can use Hasura Console to manage your app's schema, data, permissions, and event triggers.

---
## Users table
You should see all your database tables on the left-hand side of the screen. You should see multiple different **schemas** displayed as folders:
-`public` schema for your app's custom tables
-`auth` and `storage` schemas for Nhost's user management and file storage
If you open the `auth` schema, you'll see that your app already has a `users` table, so you don't have to create one.

---
## Create todos table
In Hasura Console, go to the **data** tab, then click **Create Table**. Name this table `todos`.
### Add frequently used columns
`id` and `created_at` columns are standard and can be added with two clicks. Click **Frequently used columns** and create them:
-`id` (UUID)
-`created_at` (timestamp)
Using frequently used columns ensures the columns get the right name, type, and default value.

### Add custom columns
Add two more columns manually:
-`name` (text)
-`is_completed` (boolean)
Make sure to set the default value of `is_completed` to `false`.

This is all we need! A new table will be created when you click **Add Table**.
---
## Insert data
Go to the **Insert Row** tab to add some data to your database.
Now that we have data in our database, we can retrieve it via a GraphQL API. Go to the **API** tab in the main menu. You can use this view to make GraphQL requests that query or mutate data in your database.
Paste the following GraphQL query into the form and press the "play" button:
```graphql
query{
todos{
id
created_at
name
is_completed
}
}
```
You should see the todos you just inserted show up as output on the right-hand side.
### Admin role
All requests in the Hasura Console use the `admin` role by default. This role has access to all tables and permissions.
Upgrading from Nhost v1 to v2 requires database schema and Hasura metadata changes.
---
## Upgrade Steps
### Create a new Nhost v2 app locally
:::tip
Make sure you have the [Nhost CLI](/reference/cli) installed
:::
```bash
nhost init my-nhost-v2-app
cd my-nhost-v2-app
```
### Update config
Update `config: 3` to `config: 2` in `nhost/config.yaml`. This will update Hasura's configuration version, and we need to downgrade the version when we export migrations and metadata.
### Export current migrations and metadata from Nhost v1
Make the following changes manually to your migrations.
:::tip
The migration file is located at `nhost/migrations/[timestamp]/up.sql`.
:::
- Add `OR REPLACE` after `CREATE` for the `public.set_current_timestamp_updated_at` function
- Delete all `auth.*` tables and functions (if any).
- Delete `public.users` table and everything related to the table such as constraints, triggers, etc.
- Update FK references from `public.users` to `auth.users` (if any).
### Update Metadata
Make the following changes manually to your metadata.
:::tip
The metadata is located at `nhost/metadata/tables.yaml`.
:::
- Delete tracking all tables in the `auth` schema.
- Delete tracking the `public.users` table.
- Update all references to `users` from the `public` to `auth` schema.
### Start nhost
Start Nhost locally using the [CLI](/reference/cli). From the root of your app, run:
```bash
nhost -d
```
:::tip
Running Nhost applies your local database migrations and Hasura metadata.
:::
### Restart Auth and Storage containers
Open Docker UI and restart Hasura Auth and Hasura Storage. Restarting those containers applies new metadata, effectively tracking everything in the `auth` and the `storage` schema.
### Delete migrations and metadata
Delete the local migrations and metadata.
```bash
rm -rf nhost/migrations nhost/metadata
```
### Update config (again)
Update `config: 2` to `config: 3` in `nhost/config.yaml`.
### Pull migrations and metadata from our local instance
:::tip
You can not use port `1337` in these requests. You have to use the specific port Huasra uses. Go to the Hasura Console under API and look what port Hasura is using under GraphQL Endpoint.
Nhost is the open source GraphQL backend (Firebase Alternative) and a development platform. Nhost is doing for the backend, what [Netlify](https://netlify.com/) and [Vercel](https://vercel.com/) are doing for the frontend.
We provide a modern backend with the general building blocks required to build fantastic digital products.
We make it easy to build and deploy this backend using our platform that takes care of configuration, security, and performance. Things just works and scale automatically so you can focus on your product and on your business.
## Quickstart
Get started quickly by following one of our quickstart guides:
- [Next.js](/platform/quickstarts/nextjs)
- [React](/platform/quickstarts/react)
- [RedwoodJS](/platform/quickstarts/redwoodjs)
- [Vue](/platform/quickstarts/vue)
## Products and features
Learn more about the product and features of Nhost.
The following emails can be sent as part of the authentication flow:
Nhost Auth sends out transactional emails as part of the authentication service. These emails can be modified using email templates.
- Sign up confirmation email (when using email + password)
- Reset password email (when using email + password)
- Passwordless login email (when using Magic Link)
- Confirm email change (any sign-up method)
The following email templates are available:
---
- **email-verify** - Verify email address
- **email-confirm-change** - Confirm email change to a new email address.
- **signin-passwordless** - Magic Link
- **password-reset** - Reset password
## Enabling custom email templates
Changing email templates is only available for projects on the [Pro and Enterprise plan](https://nhost.io/pricing).
If you have developed custom email templates, you must make them available over HTTP and then point Nhost to them. You can host the templates on your server, or use a public repository on GitHub.
## Update Email Templates
Go to **Users -> Login settings** and scroll down to **Custom email templates**, and set the URL to where your templates are located:
Your project must be connected to a GitHub repository using the [GitHub Integration](/platform/github-integration) to be able to change the email templates.
Email templates are automatically deployed during a deployment, just like database migrations, Hasura metadata, and Serverless Functions.
You only need to define the base URL to point to your hosted templates. The UI will give you a hint about where Nhost will look for your actual template files.
## File Structure
---
Emails are located in the `nhost/` folder like this:
## File structure
The email templates should be provided as body.html and subject.txt files in this predefined folder structure.
The email templates should be provided as body.html and subject.txt files in this predefined folder structure:
**Example:** Email templates for `en` (English) and `es` (Spanish):
```txt
// At base URL (e.g. https://yourapp.com/email-templates/)
en/
email-confirm-change/
body.html
subject.txt
email-verify/
body.html
subject.txt
password-reset/
body.html
subject.txt
signin-passwordless/
body.html
subject.txt
// Other language versions
fr/
/* ... */
se/
/* ... */
my-nhost-project/
└── nhost/
├── config.yaml
├── emails/
│ ├── en/
│ │ ├── email-verify/
│ │ │ ├── subject.txt
│ │ │ └── body.html
│ │ ├── email-confirm-change/
│ │ │ ├── subject.txt
│ │ │ └── body.html
│ │ ├── signin-passwordless/
│ │ │ ├── subject.txt
│ │ │ └── body.html
│ │ └── password-reset/
│ │ ├── subject.txt
│ │ └── body.html
│ └── es/
│ ├── email-verify/
│ │ ├── subject.txt
│ │ └── body.html
│ ├── email-confirm-change/
│ │ ├── subject.txt
│ │ └── body.html
│ ├── signin-passwordless/
│ │ ├── subject.txt
│ │ └── body.html
│ └── password-reset/
│ ├── subject.txt
│ └── body.html
├── migrations/
├── metadata/
└── seeds
```
You don’t have to provide all templates - only the one you wish to use and customize. For the templates you do provide, you must provide both body.html and subject.txt.
As you see, the format is:
[View example on GitHub](https://github.com/nhost/nhost/tree/main/examples/custom-email-templates)
---
## Localisation
If Nhost finds a template that matches the recipent user’s locale, the email will be sent in that language. Use two-letter language codes to set the locale.
English will always be used as the default if another language version is not found.
---
## Template variables
Use variables like `${displayName}` to make your templates more dynamic:
These variables can be used either in the template subject or body. The following variables are supported:
Default templates for English (`en`) and French (`fr`) are automatically generated when the project is initialized with the [CLI](/platform/cli).
## Languages
The user's language is what decides what template to send. The user's language is stored in the `auth.users` table in the `locale` column. This `locale` column contains a two-letter language code in [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) format.
This value is `en` by default for new users.
## Variables
The following variables are available to use in the email templates:
Nhost Authentication is a ready-to-use authentication service that is integrated with the [GraphQL API](/platform/graphql) and its permission system from Hasura.
Nhost provides a ready-to-use authentication service, integrated with Nhost JavaScript SDK. This makes it easy to build login flows with multiple sign-in methods.
Nhost Authentication lets you authenticate users using different sign-in methods:
## Getting Started
Sign up a user with the [Nhost JavaScript SDK](/reference/sdk):
```js
import{NhostClient}from'@nhost/nhost-js';
constnhost=newNhostClient({
backendUrl:'https://[app-subdomain].nhost.run',
});
awaitnhost.auth.signUp({
email:'joe@nhost.io',
password:'secret-password',
});
```
- [Email and Password](/platform/authentication/sign-in-with-email-and-password)
1.A user signs up and the user information is added to the `auth.users` table.
2. Nhost returns an [access token](#access-tokens) (JWT token) and the user's information.
3. The user sends a request to the GraphQL API together with the access token.
4. The GraphQL API reviews the access token to ensure the user is authorized to send the request.
1.When a user signs up or is created, the user's information is inserted into the `auth.users` table in your database.
2. Nhost returns an access token and a refresh token, together with the user's information.
3. The user sends requests to Nhost services (GraphQL API, Authentication, Storage, Functions) with the access token as a header.
4. The Nhost services use the user's access token to authorize the requests.
Nhost's authentication service is integrated with your database. All users are stored in the app's database under the `auth` schema and can be accessed using GraphQL:
```graphql
query{
users{
id
displayName
avatarUrl
email
}
}
```
## Tokens
Nhost authentication uses two tokens: Access tokens and refresh tokens.
[Nhost JavaScript SDK](/reference/sdk) automatically handles access and refresh tokens.
### Access tokens
An access token is used to authenticate and authorize a user when doing a GraphQL request.
Access tokens are cryptographically signed and cannot be revoked. They are only valid for 15 minutes. Users can request a new valid access token with a refresh token.
An access token includes a user's ID and roles. Here's an example:
To start with social sign-in, select your app in Nhost Console and go to **Users** → **Login settings**.
You need to set client ID and client secret for each provider that you want to enable.
---
## Implementing sign-in experience
Use the [Nhost JavaScript SDK](/reference/sdk) and the `signIn()` method to implement social sign-in in your app,
Here's an example of how to implement sign-in with GitHub:
```js
nhost.auth.signIn({
provider:'github',
});
```
Users are redirected to your Nhost app's **client URL** by default. By default your Nhost app's client URL is set to `http://localhost:3000`. You can change the value of your client URL in the Nhost console by going to **Users** → **Login settings** → **Client URL**.
---
## Provider OAuth scopes
Scopes are a mechanism in OAuth to allow or limit an application's access to a user's account.
By default, Nhost sets the scope to get the name, email and avatar for each user. Editing scope is not currently supported.
## Provider OAuth Tokens
Nhost saves both access and refresh tokens for each user and provider in the `auth.user_providers` table. These tokens can be used to interact with the provider if needed.
To sign in a user with email and password, the user must first sign up:
```js
awaitnhost.auth.signUp({
email:'joe@nhost.io',
password:'secret-password',
});
```
If you've turned on email verification in your app's **login settings**, a user will be sent a verification email upon signup. The user must click the verification link in the email before they can log in.
Once a user has been signed up (and optionally verified), you can sign them in:
```js
awaitnhost.auth.signIn({
email:'joe@nhost.io',
password:'secret-password',
});
```
---
## Passwordless email (magic link)
Users can sign in with passwordless email, also called magic link.
When a user signs in with passwordless email, Nhost will create the user if they don't already exist and send an email to the user.
When a user clicks the link in the email, they will be redirected to your app and automatically signed in.
Example in JavaScript:
```js
awaitnhost.auth.signIn({
email:'joe@nhost.io',
});
```
---
## Passwordless SMS
Users can sign in with passwordless SMS. The passwordless SMS sign in method has a flow:
First, "sign in" the user with a phone number.
```js
awaitnnhost.auth.signIn({
phoneNumber:'+467610337135',
});
```
This will create the user if the user does not already exist, and send a One Time Password (OTP) to the user's
phone number.
Use the OTP to finalize the sign-in:
```js
awaitnhost.auth.signIn({
phoneNumber:'+467610337135',
otp:'otp-from-sms',
});
```
---
## Anonymous
A user can be created anonymously. This is useful for offering a limited version of your application to your users without having them sign in first.
An anonymous user gets a user ID with the `anonymous` role. This role can be used to [set permissions in Hasura](/platform/database/permissions).
### Deanonymize users
Anonymous users can be converted to "normal" users by deanonymize the user.
Follow this guide to sign in users with email and password.
The email and password sign-in method is enabled by default for all Nhost projects.
## Sign Up
Users must first sign up to be able to sign in with Email and Password.
**Example:** Sign up users using the [Nhost JavaScript client](/reference/javascript).
```js
await nhost.auth.signUp({
email: 'joe@example.com',
password: 'secret-password'
})
```
If you've turned on email verification in your project's **Authentication Settings**, a user will be sent a verification email upon signup. The user must click the verification link in the email before they can sign in.
## Sign In
Once a user has been signed up (and optionally verified), you can sign them in.
**Example:** Sign in users using the [Nhost JavaScript client](/reference/javascript).
```js
await nhost.auth.signIn({
email: 'joe@example.com',
password: 'secret-password'
})
```
## Verified Emails
You can decide if only verified emails should be able to sign in or not. Modify the **Only allow users with verified emails to sign in.** setting in the **Authentication Settings** section under **Users** in your Nhost project.
An email-verification email is automatically sent to the user during sign-up if your project only allows to sign in users with verified emails. You can also manually send the verification email to the user using [`nhost.auth.sendVerificationEmail()`](/reference/javascript/auth/send-verification-email).
Signing up with a security key uses the same method as signing up with an email and a password. Instead of a `password` parameter, you need to set the `securityKey` parameter to `true`:
Any signed-in user with a valid email can add a security key when the feature is enabled. For instance, someone who signed up with an email and a password can add a security key and thus use it for their later sign-in!
Users can use multiple devices to sign in to their account. They can add as many security keys as they like.
- Create a new [Apple Developer account](https://developer.apple.com) if you don't have one already and sign in to the Apple Developer platform.
## Get an App ID
- Go to the [Apple Developer Dashboard](https://developer.apple.com/account/).
- Click on **Certificates, IDs & Profiles** in the left menu.
- Click on **Identifiers** in the left menu.
- Click on the "+" button in the header next to "Identifiers".
- Select **App IDs** and click **Continue**.
- Select type **App** and click **Continue**.
- Fill in the App information:
- Description.
- Bundle ID (ex. io.nhost.app or com.your-startup.app).
- Scroll down and check **Sign In With Apple**.
- Click **Continue** in the top right corner.
- Click **Register** in the top right corner.
- Click on the newly created app to see **Team ID**.
- **Team ID**: Copy and paste the **Team ID** to your Nhost OAuth settings for Apple.
## Get a Service ID
- Go to the [Apple Developer Dashboard](https://developer.apple.com/account/).
- Click on **Certificates, IDs & Profiles** in the left menu.
- Click on **Identifiers** in the left menu.
- Click on **Certificates, IDs & Profiles** in the left menu.
- Click on **Identifiers** in the left menu.
- Click on the "+" button in the header next to "Identifiers".
- Select **Service IDs** and click **Continue**.
- Fill in the Service information:
- Description.
- Identifier (Service ID) (ex. _service_.io.nhost.app or _service_.com.your-startup.app). Notice you can't use the same identifier as for the app so we recommend adding "service" at the beginning if the identifier.
- **Service ID**: Copy and paste the **Identifier (Service ID)** to your Nhost OAuth settings for Apple.
- Click **Continue** in the top right corner.
- Click **Register** in the top right corner.
- Click on the newly created service in the list of Identifiers.
- Click the checkbox to enable "Sign in with Apple".
- Click **Configure** next to "Sign in with Apple".
- Make sure your newly created Bundle ID is selected under Primary App ID.
- Add your base auth domain under "Domains and Subdomains". E.g. `<subdomain>.nhost.run`.
- Add the full callback URL under "Return URLs". E.g. `https://<subdomain>.nhost.run/v1/auth/signin/provider/apple/callback`.
- Click **Next**.
- Click **Done**.
- Click **Continue** in the top right corner.
- Click **Save** in the top right corner.
## Generate Key
- Go to the [Apple Developer Dashboard](https://developer.apple.com/account/).
- Click on **Certificates, IDs & Profiles** in the left menu.
- Click on **Keys** in the left menu.
- Click on **Create a key**.
- Fill in a name for your key.
- Click the checkbox to enable "Sign in with Apple".
- Click **Configure** next to "Sign in with Apple".
- Select your newly created App ID in the dropdown selector.
- Click **Save** in the top right corner.
- Click **Continue** in the top right corner.
- Click **Register** in the top right corner.
- **Key ID**: Copy and paste the **Key ID** to your Nhost OAuth settings for Apple.
- Click **Download** to download the key to your computer.
- **Private Key**: Copy and paste the content of the downloaded key to your Nhost OAuth settings for Apple.
## Sign In Users
Use the [Nhost JavaScript client](/reference/javascript) to sign in users:
Follow this guide to sign in users with Facebook with your Nhost App.
Follow this guide to sign in users with Facebook.
<p align="center">
<img
@@ -15,53 +16,53 @@ Follow this guide to sign in users with Facebook with your Nhost App.
/>
</p>
## Create Facebook account
## Create Facebook Account
- Create a new [Facebook account](https://www.facebook.com/) if you don't have one already.
## Create Facebook App
- Go to [Meta for Developers](https://developers.facebook.com/).
- Click **My Apps** in the top right
- Click **My Apps** in the top right.
- Click **Create App** in the top right.
- Select your **app type** (e.g. Consumer).
- Click **Next**.
- Fill in the **Display name.**
- Fill in the **Display name**.
- Click **Create app**.
## Set up Facebook Login
- Click on Add Product in the left menu.
- Click on Setup in the Facebook login card.
- Click on **Add Product** in the left menu.
- Click on **Setup** on the Facebook login card.
- **Don't** complete the quickstart. Instead, follow the next step.
- Click on **Settings** under **Facebook Login** in the left menu.
- Make sure **Embedded Browser OAuth Login** is set to **Yes**.
- Fill in **Valid OAuth Redirect URIs** with your **OAuth Callback URL** from Nhost.
- Click **Save changes**.
## Activate Facebook permissions and features
## Activate Facebook Permissions and Features
To make sure we can fetch all user data (email, profile picture and name). For that we need to enable **email** and **public_profile** permissions.
- Click on App Review and Permission and Features in the left menu
- Search and for **email** in the **Search Permissions and Features** search box**.**
- Click on App Review and Permission and Features in the left menu.
- Search for **email** in the **Search Permissions and Features** search box.
- Click on Request advanced access and complete the steps.
- Search and for **public_profile** in the **Search Permissions and Features** search box**.**
- Search for **public_profile** in the **Search Permissions and Features** search box.
- Click on **Request advanced access** and complete the steps.
## Configure Nhost
- Click **Settings** and then **Basic** in the left menu.
- Copy and paste the **App ID (Client ID)** and **App secret (Client Secret)** from Facebook to your Nhost OAuth settings for Facebook. Make sure the [OAuth provider is enabled in Nhost](/platform/authentication/social-sign-in#enabling-social-sign-in-provider).
- Copy and paste the **App ID (Client ID)** and **App secret (Client Secret)** from Facebook to your Nhost OAuth settings for Facebook. Make sure the OAuth provider is enabled in Nhost.
- Click the checkbox “**I have pasted the redirect URI into Facebook”**.
- Click **Confirm settings**.
## Sign In users in your app
## Sign In Users
Use the [Nhost JavaScript client](/reference/sdk) to sign in users in your app:
Use the [Nhost JavaScript client](/reference/javascript) to sign in users:
Follow this guide to sign in users with GitHub with your Nhost App.
Follow this guide to sign in users with GitHub.
<p align="center">
<img
@@ -15,7 +16,7 @@ Follow this guide to sign in users with GitHub with your Nhost App.
/>
</p>
## Create GitHub account
## Create GitHub Account
- Create a new [GitHub account](https://github.com/signup) if you don't have one already.
@@ -23,30 +24,30 @@ Follow this guide to sign in users with GitHub with your Nhost App.
- Create a new OAuth application [(direct link)](https://github.com/settings/applications/new) by:
- Click on your profile photo in the top right.
- Click on Settings
- Click on Settings.
- In the left menu, click Developer settings at the bottom.
- Click on Oauth Apps in the left menu
- Click on New OAuth App button in the top right
- Click on Oauth Apps in the left menu.
- Click on New OAuth App button in the top right.
## GitHub OAuth App information
## GitHub OAuth App Information
- Fill in Application Name
- Fill in Homepage URL
- Fill in **Authorization callback URL** with your OAuth Callbacke URL from Nhost
- Fill in Application Name.
- Fill in Homepage URL.
- Fill in **Authorization callback URL** with your OAuth Callbacke URL from Nhost.
## Configure Nhost
- Click Generate a new client secret to generate a OAuth client secret.
- Copy and paste the **Client ID** and **Client Secret** from GitHub to your Nhost OAuth settings for GitHub. Make sure the [OAuth provider is enabled in Nhost](/platform/authentication/social-sign-in#enabling-social-sign-in-provider).
- Click Generate a new client secret to generate an OAuth client secret.
- Copy and paste the **Client ID** and **Client Secret** from GitHub to your Nhost OAuth settings for GitHub. Make sure the OAuth provider is enabled in Nhost.
- Click the checkbox “**I have pasted the redirect URI into GitHub”**.
- Click **Confirm settings**.
## Sign In users in your app
## Sign In Users
Use the [Nhost JavaScript client](/reference/sdk) to sign in users in your app:
Use the [Nhost JavaScript client](/reference/javascript) to sign in users:
Follow this guide to sign in users with Google with your Nhost App.
Follow this guide to sign in users with Google.
<p align="center">
<img
@@ -15,17 +16,17 @@ Follow this guide to sign in users with Google with your Nhost App.
/>
</p>
## Sign up for Google
## Sign Up for Google
- Sign up for [Google Cloud](https://cloud.google.com/free) if you don’t have one already.
- Sign up for [Google Cloud](https://cloud.google.com/free) if you don't have one already.
## Create a Google Cloud Project
> 💡 You can skip this step if you already have a Google Cloud project you want to use.
- Create a new Google Cloud project if you don’t already have a project you want to use.
- Create a new Google Cloud project if you don't already have a project you want to use.
## Configure OAuth consent screen
## Configure OAuth Consent Screen
- Search for **OAuth consent screen** in the top search bar in the Google Cloud Console.
- Click on **OAuth consent screen** in the search results.
@@ -33,16 +34,16 @@ Follow this guide to sign in users with Google with your Nhost App.
## **Edit app registration**
### OAuth consent screen
### OAuth Consent Screen
- Fill in your App information.
- Click **SAVE AND CONTINUE.**
- Click **SAVE AND CONTINUE**.
### Scopes
- Click **SAVE AND CONTINUE**.
### Test user
### Test User
- Click **SAVE AND CONTINUE**.
@@ -50,7 +51,7 @@ Follow this guide to sign in users with Google with your Nhost App.
- Click **BACK TO DASHBOARD**.
## Create credentials
## Create Credentials
- Click on **Credentials** under **APIs & Services** in the left menu.
- Click **+ CREATE CREDENTIALS** and then **OAuth client ID** in the top menu.
@@ -60,17 +61,17 @@ Follow this guide to sign in users with Google with your Nhost App.
## Configure Nhost
- A modal appears with your Google Client ID and Client secret.
- A modal appears with your Google Client ID and Client Secret.
- Copy and paste the **Client ID** and **Client Secret** from Google to your Nhost OAuth settings for Google. Make sure the OAuth provider is enabled in Nhost.
- Click the checkbox “**I have pasted the redirect URI into Google”**.
- Click **Confirm settings**.
## Sign In users in your app
## Sign In Users
Use the Nhost JavaScript client to sign in users in your app:
Follow this guide to sign in users with Spotify with your Nhost App.
Follow this guide to sign in users with Spotify.
<p align="center">
<img
@@ -15,7 +16,7 @@ Follow this guide to sign in users with Spotify with your Nhost App.
/>
</p>
## Create Spotify account
## Create Spotify Account
- Create a new [Spotify account](https://www.spotify.com/) if you don't have one already.
@@ -23,13 +24,13 @@ Follow this guide to sign in users with Spotify with your Nhost App.
- Go to the [Spotify Developer Dashboard](https://developer.spotify.com/dashboard/).
- Click on CREATE AN APP.
- Fill in a App name and App description
- Check the box to aggre Spotify's [Developer Terms of Service](https://developer.spotify.com/terms) and [Branding Guidelines](https://developer.spotify.com/branding-guidelines).
- Fill in an App name and App description.
- Check the box to agree Spotify's [Developer Terms of Service](https://developer.spotify.com/terms) and [Branding Guidelines](https://developer.spotify.com/branding-guidelines).
## Configure OAuth Callback URL
- Click EDIT SETTINGS
- A modal appears
- Click EDIT SETTINGS.
- A modal appears.
- Fill in **Redirect URIs** with your **OAuth Callback URL** from Nhost.
- Click ADD to add the OAuth callback URL.
- Click SAVE.
@@ -41,12 +42,12 @@ Follow this guide to sign in users with Spotify with your Nhost App.
- Click the checkbox “**I have pasted the redirect URI into Spotify”**.
- Click **Confirm settings**.
## Sign In users in your app
## Sign In Users
Use the [Nhost JavaScript client](/reference/sdk) to sign in users in your app:
Use the [Nhost JavaScript client](/reference/javascript) to sign in users:
- Create a new [Twitch account](https://twitch.tv/) if you don't have one already.
## Create Twitch App
- Sign in to the [Twitch Developer Console](https://dev.twitch.tv/console).
- Click on **Register Your Application**.
- Fill in a **Twitch application name**.
- Copy and paste the callback URL from your Nhost OAuth settings for Twitch to the input field under **OAuth Redirect URLs** and click **Add** to the right of the input field.
- Select an application **Category**. E.g. _Application Integration_.
- Click **Create**.
## Get Twitch Appplication Client ID and Client Secret
- Click on **Manage** on your newly created Twitch application.
- Copy the **Client ID** and paste it into your Nhost OAuth settings for Twitch.
- Click on **New Secret** to generate a new client secret.
- Copy the **Client Secret** and paste it into your Nhost OAuth settings for Twitch.
## Sign In Users
Use the [Nhost JavaScript client](/reference/javascript) to sign in users:
To start with social sign-in, select your project in Nhost Dashboard and go to **Users** → **Authentication Settings**.
You need to set the Client ID and Client Secret for each provider that you want to enable.
## Implementing sign-in experience
Use the [Nhost JavaScript SDK](/reference/javascript) and the `signIn()` method to implement social sign-in for your project.
Here's an example of how to implement sign-in with GitHub:
```js
nhost.auth.signIn({
provider: 'github'
})
```
Users are redirected to your Nhost project's **client URL** by default. By default, your Nhost project's client URL is set to `http://localhost:3000`. You can change the value of your client URL in the Nhost console by going to **Users** → **Authentication Settings** → **Client URL**.
Here is an example of how to redirect to another host or path:
Scopes are a mechanism in OAuth to allow or limit an application's access to a user's account.
By default, Nhost sets the scope to get the name, email, and avatar URL for each user. Editing scope is not currently supported.
## Provider OAuth Tokens
Nhost saves both access and refresh tokens for each user and provider in the `auth.user_providers` table. These tokens can be used to interact with the provider if needed.
Nhost Authentication makes use of two types of tokens:
- **Access token** - used to authenticate a user and access APIs.
- **Refresh token** - used to get a new access token.
Users get both an access token and a refresh token when they sign in.
:::info
If you're using the [Nhost JavaScript client](/reference/javascript), all tokens are automatically set and updated for you. But it can still be good to understand how they work.
:::
## Access Token
An access token (also called [JSON Web Token or JWT](https://en.wikipedia.org/wiki/JSON_Web_Token)) contains information about the user such as the user id. Users send this token to the Nhost services (GraphQL, Auth, Storage, Serverless Functions) to let the services know who's making the request so the services can verify the user's identity and resolve the correct permissions.
The access token is added as an `Authorization` header when making a request, like this:
The token contains information about the user id, default role, allowed roles, if the user is anonymous or not, and other metadata.
The claims under `https://hasura.io/jwt/claims` are the same claims that are used by the GraphQL API to create [permissions](/platform/graphql/permissions). The claims (`x-hasura-*`) are also called permission variables. It's possible to add custom [permission variables](/platform/graphql/permissions#custom-permission-variables).
:::info
You can manually decode an access token using [JWT.io](https://jwt.io/).
:::
The token is cryptographically signed by Nhost Authentication, which means that all other Nhost services can trust the information in the token.
:::info
Use the `NHOST_JWT_SECRET` [system environment variable](/platform/environment-variables#system-environment-variables) to verify access tokens in [Serverless Functions](/platform/serverless-functions). Here's a guide on how to [Get the authenticated user in a Serverless Function](https://github.com/nhost/nhost/discussions/278).
:::
The access token can not be revoked. Instead, the token is only valid for 15 minutes. The user can get a new access token by using the refresh token.
## Refresh Token
A refresh token is used to request a new access token. Refresh tokens are long-lived tokens stored in the database in the `auth.refresh_tokens` table.
Refresh tokens are valid for 30 days.
To revoke a refresh token, simply delete it from the database.
Users are saved in the database in the `auth.users` table and are accessible via the GraphQL API.
---
## Querying users
Example of getting all users in GraphQL:
```graphql
query{
users{
id
displayName
email
}
}
```
Example of getting one user in GraphQL:
```graphql
query{
user(id:"<user-id>"){
id
displayName
email
}
}
```
---
## Creating users
Users should be created using the sign-up or sign-in flows as described under [sign-in methods](/platform/authentication/sign-in-methods).
**Never** create users directly via GraphQL or database. **Never** modify the `auth.users` table. **Never** modify the GraphQL root queries.
You can update the permissions of the `auth.users` table.
---
## Roles
Each user can have one or multiple roles for API requests. You can see the roles of a user and set a default role in Nhost Console under **Users**.
Every GraphQL request is made with a specific role. This role will be used to resolve permissions when querying the database. In other words, every user can have multiple roles, but only one role will be applied for any given GraphQL request.
### Defaults
For new apps, the following roles are available:
- Available roles: `user` and `me`
- Default role: `user`
### Public role
If the user is not signed in, the `public` role will be used.
### Set request role in GraphQL
When no request role is specified, the user's default role will be used:
```js
awaitnhost.graphql.request(QUERY,{});
```
Make a GraphQL request with the `me` role:
```js
awaitnhost.graphql.request(
QUERY,
{},
{
headers:{
'x-hasura-role':'me',
},
},
);
```
If the request is not part of the user's roles, the request will fail.
Users are stored in the database in the `users` table in the `auth` schema.
## Get User Information using GraphQL
**Example:** Get all users.
```graphql
query {
users {
id
displayName
email
metadata
}
}
```
**Example:** Get a single user.
```graphql
query {
user(id: "<user-id>") {
id
displayName
email
metadata
}
}
```
## Creating Users
Users should be created using the sign-up or sign-in flows as described under [sign-in methods](/platform/authentication/sign-in-methods).
- **Never** create users directly via GraphQL or database, unless you [import users](#import-users) from an external system.
- **Never** modify the `auth.users` table.
- **Never** modify the GraphQL root queries or fields for any of the tables in the `auth` schema.
You're allowed to:
- Add and remove your GraphQL relationships for the `users` table and other tables in the `auth` schema.
- Create, edit and delete permissions for the `users` table and other tables in the `auth` schema.
## Roles
Each user can have one or multiple roles for API requests. You can see the roles of a user and set a default role in Nhost Console under **Users**.
Every GraphQL request is made with a specific role. This role will be used to resolve permissions when querying the database. In other words, every user can have multiple roles, but only one role will be applied for any given GraphQL request.
### Default Role
The default role is used when no role is specified in the GraphQL request. By default, users' default role is `user`.
### Allowed Roles
Allowed roles are roles the user is allowed to use when making a GraphQL request. Usually you would change the role from `user` (the default role) to some other role because you want Hasura to use a different role to resolve permissions for a particular GraphQL request.
By default, users have two allowed roles:
- `user`
- `me`
You can manage what allowed roles users should get when they sign up under **Users** -> **Roles & Permissions**.
:::info
You must also add the roles manually to the `auth.roles` table.
:::
It's also possible to give users a subset of allowed roles during signup.
**Example:** Only give the `user` role (without the `me` role) for the user's allowed roles:
```js
await nhost.auth.signUp({
email: 'joe@example.com',
password: 'secret-password'
options: {
allowedRoles: ['user']
}
})
```
### Public Role
The `public` role is used to resolve GraphQL permissions for unauthenticated users.
### Set Role for GraphQL Requests
When no request role is specified, the user's default role will be used:
```js
await nhost.graphql.request(QUERY, {})
```
Make a GraphQL request with the `me` role:
```js
await nhost.graphql.request(
QUERY,
{},
{
headers: {
'x-hasura-role': 'me'
}
}
)
```
If the request is not part of the user's allowed roles, the request will fail.
## Metadata
You can store custom information about the user in the `metadata` column of the `users` table. The `metadata` column is of type JSONB so any JSON data can be stored.
This is how you attach custom metadata to a user during sign-up:
If you have users in a different system, you can import them into Nhost. When importing users you should insert the users directly into the database instead of using the authentication endpoints (`/signup/email-password`).
It's possible to insert users via GraphQL or SQL.
### GraphQL
Make a GraphQL request to insert a user like this:
```graphql
mutation insertUser($user: users_insert_input!) {
insertUser(object: $user) {
id
}
}
```
### SQL
Connect directly to the database and insert a user like this:
Nhost CLI, or `nhost`, is a command-line interface that lets you run and manage Nhost projects locally on Mac, Linux and Windows (WSL2).
This means you get a full-featured Nhost project running locally on your machine:
- Postgres Database
- Hasura GraphQL API
- Hasura Console
- Auth
- Storage
- Serverless Functions
This way, you can develop and test local changes before you deploy them live. The CLI automatically tracks:
- Postgres database migrations
- Hasura metadata
- Serverless functions
It's recommended to commit and push changes to GitHub and use the [GitHub integration](/platform/github-integration) for Nhost to automatically deploy those changes live.
## Installation
To download and install Nhost CLI, run the following command:
- [Docker](https://www.docker.com/get-started) (must be running while using the CLI)
:::info
Make sure you have the correct permissions for Docker so you don't have to run Docker with `sudo`. See ["Post-installation steps for Linux"](https://docs.docker.com/engine/install/linux-postinstall/) from Docker's documentation.
:::
## Get started
Start by authenticating yourself to Nhost Cloud:
```
nhost login
```
Once signed in, you can list all your Nhost projects using:
```
nhost list
```
Let's start by initializing a remote Nhost project locally with the following command:
```
nhost init --remote
```
Pick a Nhost project to use then change the directory once the project initialization is completed:
```
cd my_test_app
```
Then start the Nhost project locally:
```
nhost up
```
Hasura Console starts automatically and your Nhost project is running locally.
## Subdomain and Region
Use `localhost` as the `subdomain`, and skip `region` when using the CLI and the [JavaScript SDK](/reference/javascript):
```
import { NhostClient } from '@nhost/nhost-js'
const nhost = new NhostClient({
subdomain: 'localhost',
})
```
## Emails
During local development with the CLI, all transactional emails from Authentication are sent to a local Mailhog instance, instead of to the recipient's email address. You'll see an address where after starting [`nhost up`](/reference/cli/up) where all emails are sent to.
For the example below, all emails are accessible at `http://localhost:8025`.
Event Triggers enable you to invoke webhooks when a database event happens. Event Triggers are typically used to do post-processing tasks, using custom backend code, based on database events.
Event Triggers are associated with a specific table in the database and the following event types are available:
- **INSERT** - A row is inserted into a table.
- **UPDATE** - A row is updated in a table.
- **DELETE** - A row is deleted from a table.
:::info
It's currently only possible to create Event Triggers in the Hasura Console. We're working on adding support for creating Event Triggers in the Nhost Dashboard.
:::
### Example Use Case
Let's say you're building an e-commerce application and you want to send an email to the customer when a new order is placed. Orders are stored in the `orders` table in your database.
To send out an email every time a new order is placed, you create an event trigger that listens for the `INSERT` event on the `orders` table. Now every time an order is placed, the event trigger invokes a webhook with the order information, and the webhook sends out the email.
## Create Event Trigger
Event Triggers are managed in the Hasura Console. Select **Events** in the main menu and click **Create** to add an Event Trigger.
Event Triggers and [Serverless Functions](/platform/serverless-functions) is a perfect combination to build powerful database-backend logic. Every Serverless Function is exposed as an HTTP endpoint and can be used as a webhook for Event Triggers.
### Format
When using Serverless Functions as webhooks you should configure the webhook using a combination of environment variables and endpoints like this:
The `NHOST_BACKEND_URL` is a [system environment variable](/platform/environment-variables#system-environment-variables) and available in production and in development environments using the [CLI](/platform/cli).
### Security
To make sure incoming requests to your webhook comes from Hasura, and not some malicious third party, you can use a shared webhook secret between Hasura and your webhook handler (e.g. your Serverless Function).
It is recommended to use the `NHOST_WEBHOOK_SECRET`, which is a [system environment variable](/platform/environment-variables#system-environment-variables) and available in production and in development environments using the [CLI](/platform/cli). The `NHOST_WEBHOOK_SECRET` is available both in Hasura and in every Serverless Function.
To set this up is a two-step process:
- Step 1: Add the header `nhost-webhook-secret` with the value `NHOST_WEBHOOK_SECRET` (From env var) when creating the Event Trigger in the Hasura Console.
- Step 2: Check the header `nhost-webhook-secret` for incoming requests and make sure the header is the same as the environment variable `NHOST_WEBHOOK_SECRET`.
Here is an example of how to check the header in a Serverless Function:
```js
export default async function handler(req, res) {
// Check header to make sure the request comes from Hasura
if (req.headers['nhost-webhook-secret'] !== process.env.NHOST_WEBHOOK_SECRET) {
The `NHOST_WEBHOOK_SECRET` is a [system environment variable](/platform/environment-variables#system-environment-variables) and available in production and in development environments using the [CLI](/platform/cli).
## Next Steps
- Read the full [Event Triggers documentation from Hasura](https://hasura.io/docs/latest/graphql/core/event-triggers/index/).
- Learn about the [GraphQL API](/platform/graphql).
GraphQL is a query language for APIs. It provides a complete and understandable description of the data in your API.
Every Nhost app comes with a GraphQL API, and you can connect to this API with any GraphQL client you like. Most often you'd use the client included in [Nhost SDK](/reference/sdk/graphql).
---
## GraphQL queries
You can read your app's data with a GraphQL query.
Here is a GraphQL query that selects title, body, and done for every row in your todos table.
```graphql
queryGetTodos{
todos{
title
body
isCompleted
}
}
```
Response:
```json
{
"data":{
"todos":[
{
"title":"Delete Firebase account",
"body":"Migrate to nhost.io",
"isCompleted":true
}
]
}
}
```
#### Filtering and sorting
More complex queries utilize filters, limits, sorting and aggregation.
This GraphQL query selects all items in the todo table that aren't done, with the total number of comments and the last five comments:
```graphql
queryGetTodosWithLatestComments{
todos(where:{isCompleted:{_eq:false}}){
title
body
comments(limit:5,order_by:{createdAt:desc}){
comment
createdAt
author
}
comments_aggregate{
aggregate{
count(columns:id)
}
}
}
}
```
Response:
```json
{
"data":{
"todos":[
{
"title":"Delete Firebase account",
"body":"Migrate to nhost.io",
"comments":[
{
"comment":"Let's do this",
"created_at":"2019-10-31T08:34:25.621167+00:00",
"author":"John"
},
{
"comment":"🎉",
"created_at":"2019-10-31T08:33:18.465623+00:00",
"author":"Charlie"
}
],
"comments_aggregate":{
"aggregate":{
"count":2
}
}
}
]
}
}
```
---
## GraphQL mutations
Mutations are used to insert, update or delete data.
### Inserting data
GraphQL mutation to insert data looks like this:
```graphql
mutationInsertTodo{
insert_todos(
objects:[
{
title:"Delete Firebase account"
body:"Migrate to nhost.io"
done:false
}
]
){
returning{
id
title
body
done
}
}
}
```
Response:
```json
{
"data":{
"insert_todos":[
{
"id":"bf4b01ec-8eb6-451b-afac-81f5058ce852",
"title":"Delete Firebase account",
"body":"Migrate to nhost.io",
"done":true
}
]
}
}
```
### Inserting multiple rows
Multiple rows can be inserted with an array as the objects property. This can be useful for migrating data.
```graphql
mutationInsertMultipleTodos{
insert_todos(
objects:[
{
title:"Build the front end"
body:"Mobile app or website first?"
done:false
}
{title:"Launch 🚀",body:"That was easy",done:false}
]
){
returning{
id
title
body
done
}
}
}
```
---
## Updating data
You can update existing data with an update mutation. You can update multiple rows at once.
To mark a todo as done, you would use a mutation like this:
Notice how we are using variables as the `id` and `done` variables, which lets us mark any todo as done or not done with the same mutation.
### Upsert
When you're not sure if a piece of data already exists, use an upsert mutation. It will either insert an object into the database if it doesn't exist, or update the fields of an existing object.
Unlike for update mutations, you must pass all columns to an upsert mutation.
In order to convert your insert mutation to an upsert, you need to add an `on_conflict` property. This tells Hasura which fields it should use to find duplicates.
The `on_conflict` key must be a unique key in your database:
If `update_columns` is empty, the mutation will be ignored if the object already exists.
Here we have set the `title` to a unique key, to prevent multiple tasks with the same name. We want to avoid overwriting existing todos, so the update_columns array is empty:
In this case, the insert mutation is ignored because a todo with the `title``"Delete Firebase account"` already exists, and `update_columns` is empty.
---
## Deleting data
To delete your data, use a delete mutation. This mutation will delete all `todos` where `done` is `true`:
```graphql
mutationDeleteDoneTodos{
delete_todos(where:{done:{_eq:true}}){
affected_rows
}
}
```
If you have set up foreign keys which will restrict a delete violation, you will get an error and will not be able to delete the data until all violations are solved. The simplest way to solve this is by set `On Delete Violation` to `CASCADE` when you set up a foreign Key.
---
## Subscriptions
GraphQL subscriptions are queries that use WebSockets to keep the data up to date in your app in real time:
```graphql
subscriptionGetTodos{
todos{
title
body
done
}
}
```
Your data is always in sync when using subscriptions. It does not matter if the data changes through GraphQL or directly in the database. The data is always syncing in real-time using GraphQL subscriptions.
Every Nhost project comes with its own [Postgres database](https://postgres.org/). Postgres is the world's most advanced open-source relational database and it's the most [popular SQL database for developers](https://insights.stackoverflow.com/survey/2021#section-most-loved-dreaded-and-wanted-databases).
There are three ways of managing your database:
1. Nhost Database UI (recommended).
2. Hasura Console.
3. [Connect directly to the database.](#postgres-access)
## Schemas
Generally, you should use the `public` schema for your project. It's also ok to add custom schemas for more advanced usage.
The two schemas `auth` and `storage` are reserved for [Nhost Auth](/platform/authentication) and [Nhost Storage](/platform/storage). You're allowed to modify **permissions** and **add relationships**. However, never modify any tables or remove relationships that were added by Nhost inside the `auth` and `storage` schemas.
## Manage Tables
### Create Table
1. Go to **Database** in the left menu.
2. Click **New table**.
3. Enter a **name** for the table.
4. Add **columns**.
5. Select a **Primary Key** (usually the `id` column).
6. (Optional) Select an **Identity** column. Identity is for integer columns only and is usually selected for the `id` column so the `id` is automatically incremented (1,2,3...) on new rows.
7. (Optional) Add **Foreign Keys**.
8. Click **Create**.
When a table is created it is instantly available through the [GraphQL API](/platform/graphql).
Here's an example of how to create a `customers` table:
It's possible to access your Postgres database directly with your favorite Postgres client.
:::info
For projects older than September 2022, it's not possible to connect directly to the database via a connection string. We're working on a one-click fix that can be expected to be available in October 2022.
:::
Go to **Settings** in the left menu and click on **Database**. You'll find the connection string and credentials to connect to your database.
To track database changes, use the [Nhost CLI](/platform/cli) to develop locally and use our [GitHub integration](/platform/github-integration) to automatically deploy database migrations live.
1. Develop locally using the Nhost CLI.
2. Push changes to GitHub.
3. Nhost automatically deploys changes.
Learn how to [get started with Nhost CLI](/platform/overview/get-started-with-nhost-cli).
## Seed Data
Seed data is a way of automatically adding data to your database using SQL when a new environment is created. This is, for the moment, only applicable when you're using the [Nhost CLI](/platform/cli) to develop locally. When you're running `nhost up` for the first time, seed data is added.
In the future, seed data will also be added to new preview environments.
Seed data should be located in `nhost/seeds/default/` and are executed in alphabetical order.
**Example:** Two seed scripts with countries and products.
```text
nhost/seeds/default/001-countries.sql
nhost/seeds/default/002-products.sql
```
## Backups
Databases on the [Pro and Enterprise plans](https://nhost.io/pricing) are automatically backed up daily.
## Best Practices
- Use lower-case names for tables. E.g. `customers` instead of `Customers`.
- Use plural names for tables. E.g. `customers` instead of `customer`.
- use underscore (`_`) instead of camelCase for table names. E.g. `customer_invoices` instead of `customerInvoices`.
- use underscore (`_`) instead of camelCase for column names. E.g. `first_name` instead of `firstName`.
## Next Steps
- [Learn PostgreSQL Tutorial - Full Course for Beginners (YouTube)](https://www.youtube.com/watch?v=qw--VYLpxG4).
- Learn more about how to manage your [Postgres database in Hasura](https://hasura.io/docs/latest/graphql/core/databases/postgres/schema/index/).
- Learn about the [GraphQL API](/platform/graphql).
The GraphQL API is protected by a role-based permission system based on access tokens. Permissions are handled on a per-table basis in Hasura Console.
---
## How it works
Upon login a user gets an access token which is then being sent with every GraphQL API request to authenticate the user and apply the correct permissions when reading and writing data.
In Hasura you can specify what a user is allowed to do. A common use case is to allow a user to read something if `user_id` in the database is equal to the user ID in the access token.
Access token data is included as headers with every API request. By default, every user has the following session variables that can be used when creating permission rules:
-`x-hasura-user-id`
-`x-hasura-allowed-roles`
-`x-hasura-default-role`
The default role for users is `user`.
> You can also [add custom permission](#add-permission-variables) varaibles if you need to.
One of the most common permission requirements is that logged-in users should only be able to read their own data. This is how it can be achieved with Hasura.
1. Go to **Hasura Console**
1. Select your table and open the **Permissions** tab
1. At the top of the page, click **"select"** on the **"user"** role.
1. Select **"With custom check"** to create a new rule
1. Enter `user_id`, `_eq` and `x-hasura-user-id` into the rule form.
This means that in order for users to read data, the user ID value in the database row must be the same as the user ID in the access token.
To further refine this rule, do the following:
1. Limit number of rows to 100 (or some other relevant number).
1. Select the columns you want the user to be able to read. In our case we'll allow the user to read all columns.
Note that if you add columns to your table table later, you must check new columns here to let users read them.
Here is a popular approach for insert permission for logged in users.
1. At the top of the page, click **"insert"** on the **"user"** role.
1. Select **"Without any checks"**.
1. Select the columns you want to allow users to insert.
In our example, we only select `name`, because we want all other other columns to be filled with default values.
We also want every new record's `user_id` value to be set to the ID of the user making the request. We can tell Hasura to do this with **column presets**.
1. Under column presets, set `user_id` to `x-hasura-user-id`.
## Add Permission Variables
You can add extra permission variables in the Nhost console under **Users** and then **Roles and permissions**. These permission variables are then available when creating permissions for your GraphQL API in the Hasura console.
As an example, let's say you add a new permission variable `x-hasura-organisation-id` with path `user.profile.organisation.id`. This means that Nhost Auth will get the value for `x-hasura-organisation-id` by internally generating the following GraphQL query:
Every Nhost app comes with a Postgres database. Postgres is the world's most advanced open-source relational database and the most popular SQL database among developers. The database is hosted with Amazon RDS.
Tables are managed in the Hasura Console.
---
## Creating tables
1. In Hasura Console, go to the **Data** tab, select the **public** schema in the left menu and click **Create Table**
2. Enter a table name
3. Add table columns
4. Add a primary key (usually the ID column)
5. (Optional) Add foreign keys
6. (Optional) Add unique keys
7. Click **Add Table**
When a table is created, the table is created in Postgres and added to your GraphQL API.
#### Schemas
You should use the `public` schema when developing your app. `auth` and `storage` are reserved for system functionality like user and file management. You are allowed to modify permissions for tables in the `auth` and `storage` schemas, however.
---
## Modifying table schema
1. In Hasura Console, go to the **Data** tab and click on the table you want to edit in the left menu
2. Click **Modify**
3. Modify or add table columns
#### Track foreign-key relations
1. Click on Data in the top menu.
2. A list of untracked foreign-key relations is presented.
3. Click Track All (recommended) or click Track for each relationship you want to track.
---
## Deleting tables
1. In Hasura Console, go to the **Data** tab and select the table you want to delete in the left menu
2. Click **Modify**
3. Scroll to the bottom of the page and click **Delete table** to open the confirmation dialog
Environment Variables are key-value pairs configured outside your source code. They are used to store environment-specific values such as API keys.
You can manage your project's Environment Variables in Nhost Dashboard under **Variables**. When you define a new variable, you can set one value for **production** and one for **development**.
When an Environment Variable is changed, you must deploy your project again using the [GitHub integration](/platform/github-integration) for the changes to take effect.
Environment Variables are available in:
- Hasura
- Serverless Functions
## System Environment Variables
System Environment Variables are automatically available in production and during development. The following system Environment Variables are available:
When developing locally using the [CLI](/platform/cli), Environment Variables set in `.env.development` are available in your local environment. There are two ways to manage them:
1. Edit the `.env.development` file manually.
2. Add development Environment Variables in the Nhost Dashboard and use `nhost env pull` to sync them. This way, your team members will also have access to the same Environment Variables.
The GitHub integration allows you to automatically deploy your Nhost project when on push and merge to a GitHub repository that is connected to your Nhost project.
When a GitHub repository is connected to a Nhost project, Nhost automatically deploys changes when you push code to the repo.
The following things are deployed:
- Database migrations
- Hasura metadata
- Serverless Functions
:::info
Settings in `nhost/config.yaml` are **not** deployed. That means you need to manually sync settings between local and remote environments between the CLI and Nhost Cloud.
:::
## Connecting a GitHub repository
1. From your Nhost project, click **Connect to Github**.

2. **Install the Nhost project** on your Github account.

If your Nhost project is not at the root of your git repository (typically when using a monorepo), you can set a custom base directory. The base directory is where the `nhost` directory is located. In other words, the base directory is the **parent directory** of the `nhost` folder.
A GraphQL API is automatically and instantly available based on the tables and columns in your [database](/platform/database).
The GraphQL API has instant support for inserting, selecting, updating, and deleting data, which usually account for 80% of all API operations you need.
It's the [Hasura GraphQL engine](https://github.com/hasura/graphql-engine) that powers the GraphQL API which means that all documentation about [queries](https://hasura.io/docs/latest/graphql/core/databases/postgres/queries/index/), [mutations](https://hasura.io/docs/latest/graphql/core/databases/postgres/mutations/index/), and [subscriptions](https://hasura.io/docs/latest/graphql/core/databases/postgres/subscriptions/index/) from Hasura's documentation is applicable.
## What is GraphQL
GraphQL is a query language for APIs that prioritize developer experience. The GraphQL API can be used to both fetch (query) and modify (mutation) data. GraphQL is especially powerful for frontend developers who want to build products fast.
GraphQL has grown rapidly in popularity in the last years and has been adopted by almost all major tech companies such as Facebook, GitHub, and Stripe.
Building your GraphQL API is a lot of work, but with Nhost it's easy because every table and column is instantly available in your GraphQL API.
## Endpoint
The GraphQL API is available at `https://[subdomain].nhost.run/v1/graphql` When using the [CLI](/platform/cli) the GraphQL API is available at `http://localhost:1337/v1/graphql`.
## GraphQL Clients for JavaScript
The Nhost JavaScript client comes with a simple [GraphQL client](/reference/javascript/nhost-js/graphql) that works well for the backend or simple applications.
When building more complex frontend applications, we recommend using a more advanced GraphQL client such as:
A GraphQL query is used to fetch data from the database.
:::tip
The [Queries documentation from Hasura](https://hasura.io/docs/latest/graphql/core/databases/postgres/queries/index/) is applicable since we're using Hasura's GraphQL Engine for your project.
:::
**Example:** A GraphQL query to select `title`, `body`, and `isCompleted` for every row in the `todos` table.
```graphql title=GraphQL
query GetTodos {
todos {
title
body
isCompleted
}
}
```
**Response:**
```json title=Response
{
"data": {
"todos": [
{
"title": "Delete Firebase account",
"body": "Migrate to Nhost",
"isCompleted": true
}
]
}
}
```
#### Filtering and sorting
More complex queries utilize filters, limits, sorting, and aggregation.
Here's an example of a more complex GraphQL query that selects all items in the `todos` table that aren not completed, with the total number of comments and the last five comments:
A GraphQL mutation is used to insert, upsert, update, or delete data.
:::tip
The [Mutations documentation from Hasura](https://hasura.io/docs/latest/graphql/core/databases/postgres/mutations/index/) is applicable since we're using Hasura's GraphQL Engine for your project.
Notice how we are using variables as the `id` and `isDone` variables, which lets us mark any todo as completed or not completed with the same mutation.
### Upsert Data
When you're not sure if a piece of data already exists, use an upsert mutation. It will either insert an object into the database if it doesn't exist or update the fields of an existing object.
Unlike for update mutations, you must pass all columns to an upsert mutation.
To convert your insert mutation to an upsert, you need to add an `on_conflict` property for the GraphQL API to know which fields it should use to find duplicates.
The `on_conflict` key must be a unique key in your database:
If `update_columns` is empty, the mutation will be ignored if the object already exists.
Here we have set the `title` to a unique key, to prevent multiple tasks with the same name. We want to avoid overwriting existing todos, so the update_columns array is empty:
In this case, the insert mutation is ignored because a todo with the `title` `"Delete Firebase account"` already exists, and `update_columns` is empty.
### Delete Data
To delete your data, use a delete mutation. This mutation will delete all `todos` where `done` is `true`:
```graphql title="GraphQL mutation"
mutation DeleteDoneTodos {
delete_todos(where: { done: { _eq: true } }) {
affected_rows
}
}
```
If you have set up foreign keys which will restrict a delete violation, you will get an error and will not be able to delete the data until all violations are solved. The simplest way to solve this is by set `On Delete Violation` to `CASCADE` when you set up a foreign Key.
---
## Subscriptions
GraphQL subscriptions are queries that use WebSockets to keep the data up to date in your app in real-time. You only have to change `query` to `subscription` when constructing the GraphQL document:
```graphql title="GraphQL subscription"
subscription GetTodos {
todos {
title
body
done
}
}
```
Your data is always in sync when using subscriptions. It does not matter if the data changes through GraphQL or directly in the database. The data is always syncing in real-time using GraphQL subscriptions.
The GraphQL API is protected by a role-based permission system.
For each **role**, you create **rules** for the **select**, **insert**, **update**, and **delete** operations.
**Example:** Let's say you have a `posts` table, and you want users to only access their own posts. This is how you would do it:
```sql title="Posts Table"
CREATE TABLE "public"."posts" (
"id" serial NOT NULL PRIMARY KEY,
"title" text NOT NULL,
"user_id" uuid NOT NULL,
);
```
```json title="Hasura Permission Rule"
{
"user_id": {
"_eq": "X-Hasura-User-Id"
}
}
```
The rule above make it so users can only select posts where the value of `user_id` is equal (`_eq`) to their user ID (`x-hasura-user-id`).
## What is `x-hasura-user-id`?
`x-hasura-user-id` is a permission variable that is used to create permission rules in Hasura. The permission variable comes from the [access token](platform/authentication#access-tokens) that signed-in users have.
The `x-hasura-user-id` permission variable is always available for all signed-in users. You can add [custom permission variables](#custom-permission-variables) to create more complex permission rules unique to your project.
## Custom Permission Variables
You can add custom permission variables in the Nhost console under **Users** and then **Roles and permissions**. These permission variables are then available when creating permissions for your GraphQL API in the Hasura console.
**Example:**: Let's say you add a new permission variable `x-hasura-organisation-id` with path `user.profile.organisation.id`. This means that Nhost Auth will get the value for `x-hasura-organisation-id` by internally generating the following GraphQL query:
```graphql
query {
user(id: "<User's ID>") {
profile {
organisation {
id
}
}
}
}
```
### Local Custom Permission Variables
To use custom permission variables locally, add your claims to the `config.yml` as following:
Your custom claim will be automatically prefixed with `x-hasura-`, therefore, the example above results in a custom permission variable named `x-hasura-organisation-id`.
### Limitation on JSON/JSONB columns
JSON columns cannot be used in custom claims, with the exception of the `users.metadata` column.
## Roles
Every GraphQL request is resolved based on a **single role**. Roles are added in the Hasura Console when selecting a table and clicking **Permisisons**.
If the user is not signed in, the GraphQL API resolves permissions using the `public` role.
### Default Role
Every user have one **default role**. The default role is used to resolve permissions if no other role is specified using the `x-hasura-role` header in the GraphQL request. By default, the default role is `user` for signed-in users.
### Allowed Roles
Every user also has a one or more **allowed roles**. Allowed roles are roles that the user is allowed to use to override the default role when making a GraphQL request. To override the default role, add a header `x-hasura-role = <role>` to the GraphQL request.
## Public Access
GraphQL requests from unauthenticated users are resolved using the `public` role.
Here is a popular approach for insert permission for signed-in users.
1. At the top of the page, click **"insert"** on the **"user"** role.
2. Select **"Without any checks"**.
3. Select the columns you want to allow users to insert.
In our example, we only mark `title`, because the other columns should not be inserted by the user.
We also want every new record's `user_id` value to be set to the ID of the user making the request. We can tell Hasura to do this using **Column presets**.
4. Under **Column presets**, set `user_id` to `x-hasura-user-id`.
Now, users who are signed-in can insert posts. Users can add a title when inserting a post. The post's `id` is automatically generated by the database and the `user_id` is automatically set to the user's id using the `user_id = x-hasura-user-id` column preset.
## Select, Update and Delete Permissions
Select, update, and delete permissions usually follows the same pattern. Here's an example of how to add select permissions:
Environment variables are key-value pairs configured outside your source code. They are used to store environment-specific values such as API keys.
---
## System environment variables
System environment variables are automatically available in production and local development. The following system environment variables are available:
You can manage your app's environment variables in Nhost Console under **Variables**. When you define a new variable, you can set a different value for production and local development.
When an environment variable is changed, you must deploy your app again for the changes to take effect.
---
## Local environment variables
When developing locally, environment variables set in `.env.development` are available in your local environment. There are two ways to manage them:
1. Edit the `.env.development` file manually.
2. Add development environment variables in the Nhost Console and use `nhost env pull` to sync them. This way, your team members will also have access to the same variables.
You can connect your Nhost app to a GitHub repository. When you do this, any updates you push to your code will automatically be deployed.
---
## Production branch
Nhost will only deploy your production branch. By default this will match the default branch set on GitHub (usually `main`). You can change this option on Nhost Console.
Specifically, the following will be deployed:
- Database migrations
- Hasura metadata
- Serverless functions
---
## Workflow
Create a new Nhost app. Then use [Nhost CLI](/platform/nhost/local-development) to initialize your Nhost app locally.
The workflow is as follows:
1. Make local changes (migrations, metadata, functions)
2. Push changes to GitHub
3. Nhost automatically applies changes to production
**You should always follow this workflow.** Never change things in production directly because that will make the local and production state to be out of sync.
### Local and production branches out of sync
If you do changes directly in your production backend, say you add a new table in production, your migrations in your repository will be out of sync. In such a case, we recommend to start over with `nhost init --remote` to get into a consistent state.
- [Git](https://git-scm.com/downloads) must be installed on your system
- [Docker](https://www.docker.com/get-started) must be installed and running when using Nhost CLI
### Function runtimes
To run serverless functions locally, you must have the appropriate runtimes installed on your machine:
- JavaScript and TypeScript functions: `Node.js 14.*`
For Node.js, you will also need to have [express](https://www.npmjs.com/package/express) installed in your repository:
```bash
npm install --save-dev express @types/express
```
[Read more about runtimes](/platform/serverless-functions)
---
## Windows support
If you have Windows Subsystem for Linux and `curl` in your Windows environment, you run the command following the instructions above. It will download the `.exe` binary to your current working directory.
If you do not have the above dependencies, download and install the latest release manually from [GitHub releases](https://github.com/nhost/cli/releases).
---
## Apple silicon (M1)
As of late 2021, Hasura does not yet have an M1 optimized version for their GraphQL engine, which Nhost depends on.
If you have a MacBook with an M1 chip, the CLI will automatically change the image used in `nhost/config.yaml` of your app:
```yml
services:
hasura:
image:fedormelexin/graphql-engine-arm64
```
This will run the Hasura GraphQL engine using Rosetta on your machine until an M1 optimized image is launched.
---
## Upgrading
If you already Nhost CLI installed, you can upgrade your installation:
Nhost is a backend as a service built with open source tools to provide developers the general building blocks required to build fantastic digital apps and products.
Here's a diagram of the Nhost stack on a high level:
There are three things the Nhost CLI and the GitHub integration track and apply
to production:
- Database Migrations
- Hasura Metadata
- Serverless Functions
:::caution
Settings in `nhost/config.yaml` are not being applied to production. They only work locally for now.
:::
### Database migrations
Database changes are tracked and managed through migrations.
:::tip
You must use the Hasura Console to make database changes. With the Hasura Console, database migration files are automatically generated incrementally to track database changes for you.
:::
To demonstrate how to make database changes, let's create a new table called
`messages`, with the following columns:
- `id` (type UUID and default `gen_random_uuid()`),
- `text` (type Text),
- `authorId` (type UUID),
- `createdAt` (type Timestamp and default `now()`)
In the Hasura Console, go to the **DATA** tab section and click on the
PostgreSQL database (from the left side navigation) that Nhost provides us.
Click on the **public** schema and then the **Create Table** button.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.