Introducing live reloading on the cloud for faster development

Make your application on the cloud reload by modifying the source code on your computer

What is live-reloading?

Before we get to the feature, it is better to clarify what I mean by live-reloading. Live-reloading is when the compile/build step runs automatically every time your source code changes. This makes it faster for you to test your work as you write code. This is especially helpful for web development. Common live reloading tools are:

  • Nodemon for NodeJS
  • Webpack for JavaScript frameworks like React, AngularJS etc
  • Gin for Golang

For other languages and frameworks, check awesome-live-reloading where we have curated live-reloading tools for different languages and frameworks.

Deploying apps to the cloud

You can deploy your custom code on a Hasura cluster (running on the cloud) as a microservice. Hasura microservices could be your own apps in the languages/framework of your choice, cronjobs, webhooks or existing docker images.

If you have deployed your app on a Hasura cluster as a microservice, the app is containerised with Docker and deployed with Kubernetes. If that sounds scary, just think of it like: your source code (along with its dependencies) is put in a box (running some OS) and this box is deployed on the cloud by a wizard that is extremely proficient in dealing with such boxes. This box is a Docker container and the wizard is Kubernetes.

More about Hasura microservices …

Introducing Microservice Sync

hasura microservice sync is a command that syncs the source code of your app in your local directory with the source code of your app in the Docker container deployed on the cloud. This means, if your Docker container is running a command that watches the source code changes inside the container, you can make it watch the changes in your local directory too.

The command looks like:

$ hasura microservice sync <microservice-name> <local-source-code-path>:<container-source-code-path> [flags]

For example, if I want to sync a NodeJS microservice called api deployed on Hasura, with the source code on my computer, the command, when run from the source code directory, will look something like:

$ hasura microservice sync api ./:/src

In the above command, ./ is the present working directory and /src is the source code directory in the Docker container.

Here is a video demo of the above example. The app in this demo is run using nodemon which is a live-reloading tool for NodeJS.

Here is the gist for the Dockerfile if you are interested.

How does it work?

When you run $ hasura microservice sync, the hasura CLI performs the following steps:

  1. Copy the local source code to the container using SSH
  2. Watch the changes in the local source code
  3. Whenever a change in a file is detected, copy that file to the container using SSH
  4. Repeat from (2)

Try it yourself

Quickly see an application on the cloud reflect the source code changes on your computer immediately. Just install the hasura CLI tool and run the following commands:

After running the above commands, you can edit microservices/ui/app/src/App.js and see your changes reflect in the browser. This quick trial is performed for React but you can use the same workflow for any language/framework.

In the above trial, for a quick trial, we have set up Dockerfile_live_reload and Dockerfile_prod in the project which you can use as Dockerfile to toggle between your environments. In case of other projects, you will have to modify the Dockerfile yourself.

Docs Reference

Live reloading local changes to a microservice


When and why should you use it?

This feature is meant to be used only in your staging, testing or development environment.

Apart from sheer coolness, there are some solid reasons to use microservice sync :

  • You can develop from a computer that does not have some or any of the dependencies installed. All you need is the source code. ❤ All hail containers ❤
  • If you want to quickly make a small fix to your app deployed on the staging server, it is much faster and less tedious to use microservice sync than deploying the whole thing again.
  • If you want to make HTTP calls to your backend from your frontend and both are running on different ports of your localhost, you will face CORS problems. So it can be helpful to deploy the two and then continue development using microservice sync.
  • If your app is querying the internal endpoints which can be queried only from the cloud, it is much more efficient to use microservice sync than other alternatives: SSH, port-forward etc.

What about logs?

You just have to use an extra flag — show-logs with the command to get realtime logging during development.

Example:

$ hasura microservice sync api ./:/src --show-logs

Some more demos

This feature can be used with every framework that supports live-reloading. Below are the demos with Python-Flask and React.

Python-Flask

This is a basic Hasura starter project that runs a Python Flask hello-world server as a microservice called app. We demo microservice sync over this app microservice. You can check out this starter project here. The Gunicorn conf has been slightly modified to set reload=True . If you are interested, you can check the Dockerfile and the gunicorn_conf.py.

React

This is a simple Hasura starter project with a create-react-app boilerplate running as a microservice called ui . microservice sync is run over this ui microservice. You can check out this project here. The Dockerfile has been slightly modified to enable hot reloading. Check out this gist for the Dockerfile.


Reference


Hasura is an open-source engine that gives you realtime GraphQL APIs on new or existing Postgres databases, with built-in support for stitching custom GraphQL APIs and triggering web hooks on database changes.