Part I: Create a Hasura project

A Hasura project is a directory (ie: a code repo) that contains all the configuration files, the database migrations, along with the source code and configuration of your custom microservices. This project directory should be a git repo, so that you can git push hasura master to deploy everything in the repo to a Hasura cluster.

Create a ‘hello-world’ project

Run the following command:

$ hasura clone hasura/hello-world
Cloning project...
✓ Project cloned directory=<dir-path>/hello-world

This will ‘clone’ the hasura/hello-world project from platform.hasura.io/hub into your current directory.

Note

hasura/hello-world is a starter project that contains a few database migrations to add a sample schema and some sample data to let you start experimenting quickly.

You can clone any project from the hub and use that as a starting point for your new project.

Understand the project structure

A Hasura project has a particular directory structure and it has to be maintained strictly, else hasura CLI will not work as expected.

Move to the project directory we just cloned.

Run the following command:

$ cd hello-world

Every Hasura project follows the below structure:

.
├── .hasura
├── hasura.yaml
├── clusters.yaml
├── conf
│   ├── authorized-keys.yaml
│   ├── auth.yaml
│   ├── ci.yaml
│   ├── domains.yaml
│   ├── filestore.yaml
│   ├── gateway.yaml
│   ├── http-directives.conf
│   ├── notify.yaml
│   ├── postgres.yaml
│   ├── routes.yaml
│   └── session-store.yaml
├── migrations
│   ├── <1504788327_create_table_user.down.yaml>
│   ├── <1504788327_create_table_user.down.sql>
│   ├── <1504788327_create_table_user.up.yaml>
│   └── <1504788327_create_table_user.up.sql>
└── microservices
    ├── <adminer>
    │   └── k8s.yaml
    └── <flask>
        ├── src/
        ├── k8s.yaml
        └── Dockerfile

Note

In our hello-world project, the microservices directories will by empty right now

hasura.yaml

This file contains some metadata about the project, namely a name and a platformVersion which says which Hasura platform version is compatible with this project. It is kind of like a requirements.txt or a package.json file you would find in python & nodejs apps respectively, and is not a file you have to worry about much during your day to day development effort.

name: <project_name>
platformVersion: v0.15.23

clusters.yaml

This file contains the configuration of your infrastructure. The idea is to have a declarative configuration of your infrastructure so that you can create instances of your infra on-demand.

version: v1
provider: digital-ocean
region: blr1
nodes:
- type: s-2vcpu-4gb
  labels:
    app: postgres
volumes:
- name: postgres
  size: 10
- name: filestore
  size: 30
- name: sessionstore
  size: 5
# custom volume
- name: my-volume
  size: 10

.hasura

Information about the actual clusters added to this project can be found in this file. Each cluster is defined by it’s name allotted by Hasura, and an alias that matches with one in clusters.yaml. While adding the cluster to the project you are prompted to give an alias, which is just hasura by default. The kubeContext mentions the name of kubernetes context used to access the cluster, which is also managed by Hasura. The data key is for holding custom variables that you can define.

clusters:
- alias: hasura
  config:
    configmap: controller-conf
    namespace: hasura
  data: null
  kubeContext: h33-blinders97
  name: h33-blinders97
defaultCluster: hasura

conf/

This directory contains the project configuration files such as HTTP routes, continuous integration remotes, etc. You can find more information about each conf file at the top of the file itself.

migrations/

This directory contains database migrations.

microservices/

This directory contains everything related to the microservices that you create; such as the Kubernetes configuration, Dockerfile for building the docker image and application source code etc.

Next: Create a Hasura cluster

Next, let’s head to Part II: Create a Hasura cluster.