Forem: Praveen Durairaju

How to Build a GraphQL API for MongoDB Using Hasura in Six Steps

Praveen Durairaju — Tue, 25 Jun 2024 19:41:00 +0000

In 2012, GraphQL was introduced as a developer-friendly API spec that allows clients to request exactly the data they need, making it efficient and fast. By reducing the need for multiple requests and limiting the over-fetching of data, GraphQL simplifies data retrieval, improving the developer experience. This leads to better applications by ensuring more efficient data loading and less bandwidth usage, particularly important for mobile or low-bandwidth environments.

Using GraphQL instead of REST on MongoDB is desirable for many use cases, especially when data from multiple MongoDB instances needs to be accessed simultaneously or when engineers need to join NoSQL data from MongoDB with data from another source.

However, engineers often encounter difficulties implementing GraphQL APIs and layering them onto their MongoDB data sources. This learning curve and the maintenance overhead often inhibit adoption. Hasura was designed to address this common challenge with adopting GraphQL.

Hasura is a low-code GraphQL API solution. With Hasura, even engineers unfamiliar with GraphQL can build feature-rich GraphQL APIs — complete with pagination, filtering, sorting, etc. — on MongoDB and dozens of other data sources in minutes.

Hasura also supports data federation, enabling developers to create a unified GraphQL API across different databases and services. In this guide, I’ll show you how to quickly connect Hasura to MongoDB and generate a secure, high-performance GraphQL API.

I will take you through the following steps to:

Create a project on Hasura Cloud
Create a database on MongoDB Atlas
Connect Hasura to MongoDB
Generate a high-performance GraphQL API instantly
Try out GraphQL queries with relationships
Analyze query execution

In addition, I will delve into the mechanics behind the generated API's exceptional performance, detailing the techniques and optimizations that contribute to its efficiency.

By the conclusion of this guide, you will possess the skills necessary to build your own high-performance, production-ready GraphQL API using Hasura, tailored for your existing or new MongoDB Atlas instance.

Step 1: Create a project on Hasura Cloud

To begin, you will need a project on Hasura Cloud and a MongoDB database on Atlas. Head over to cloud.hasura.io to create an account or log in. Once you are on the Cloud Dashboard, navigate to Projects and click on New Project to create a new project.

You can create a free project by selecting the region of your choice. In this example, we are using AWS infrastructure, US West region.

Remember the region selected. We want to co-locate the GraphQL API deployed using Hasura Cloud in the same region as the database on MongoDB Atlas. This will be done in one of the subsequent steps. Click on the Create Free Project button, as highlighted. As always, you can upgrade the project later as required.

Once the project is created, you’ll be taken to the project details page, which displays the GraphQL endpoint among other details. Take note of the Hasura Cloud IP on this page, as it’s required during the MongoDB Atlas setup to allow the connection from Hasura to MongoDB.

Click on Launch Console to open the project's Hasura Console. You will land on the API Explorer page to try out the GraphQL APIs.

Click on the DATA tab at the top to navigate to the Data Management section of the console. Here you can connect to the various databases that Hasura supports. Choose MongoDB from the list and click on Connect Existing Database.

At this point, Hasura requires the connection details of MongoDB.

Step 2: Create a database on MongoDB Atlas

Hasura can connect to a new or an existing MongoDB Atlas database and generate the GraphQL API for you. Now, go ahead and create a new database and use some autogenerated sample data.

Go to MongoDB Atlas, create a project if you don’t already have one, and navigate to the Database page under the Deployments section. You should see a page like the one below:

Click on the Build a Database button. On the next page, select the deployment specifics. Start with the Free M0 cluster, free forever and ideal for getting started. You can always upgrade later when required.

Give the cluster a name; for this example, use Hasura. You will need to select the region. For this tutorial, pick AWS as the provider and choose the us-west-2 region to keep the data close to the Hasura instance (recall that our Hasura cluster was deployed on US West, as well).

Remember to choose the region closest to your users. Keeping your database and API region the same is recommended to avoid performance and latency issues.

Next, add your IP address for local connectivity and create a new database user with atlasAdmin permission that you’ll need to access the MongoDB cluster from Hasura Cloud.

Note the password, as we will need it later. Now, click on Create Database User. Choose a connection method and skip the next steps. Optionally, in case you are stuck in any of the steps above, you can refer to the instructions for creating a new MongoDB database deployment in the docs, particularly until Step 4.

Step 3: Load sample dataset

Once the database deployment is complete, you might want to load some sample data for the cluster. You can do this by heading to the Database tab and under the newly created Cluster, click on the ... that opens an option to Load Sample Dataset. This may take a few seconds.

At this stage, we have created a Hasura Cloud project and a MongoDB Atlas database.

Step 4: Connect Hasura to MongoDB

To connect Hasura to MongoDB, first add the Hasura Cloud IP address to your MongoDB cluster. To do that, navigate to the Network Access page (under Security) from the Atlas dashboard.

Click on ADD IP ADDRESS and enter the Hasura Cloud IP that you obtained from the Hasura Cloud dashboard in the first step.

Once completed, Hasura Cloud should be able to communicate with the MongoDB Atlas instance. The next step is to get the database connection string.

On the Atlas dashboard, head to the Database page and click on Connect next to the Hasura cluster created some steps back. Choose the Drivers option.

You will get a popup with the connection string details. Copy the connection string for the database, which will be similar to this format:

mongodb+srv://praveen:<password>@hasura.1oyflxi.mongodb.net/?retryWrites=true&w=majority

Note that you need to replace <password> with the actual password of the database user that you created earlier.

You can access the Database Users from the Database Access tab under the Security section of the left navigation menu. Remember that the database user needs to have atlasAdmin permission for the connection to work.

Now, move back to the Hasura Cloud dashboard for the next step.

As you are on the Connect Existing Database for MongoDB page, enter the values for the name of the database as mongodb, the connection string copied from the previous step. This instance comes with a sample database called sample_mflix. Enter that under the db config.

Finally, click on Connect Database and you are all set with the connection of Hasura and MongoDB, all hosted on their respective Cloud instances.

Step 5: Generate a high-performance GraphQL API

You can generate an API instantly for the sample database that was loaded to MongoDB by going to the mongodb -> Manage page on Hasura Console.

Review the collections from the sample database shown on this page. For example, you can see collections such as users, theaters, movies, comments, sessions, and embedded_movies. Now you can Track them to make sure Hasura generates the GraphQL (and REST) API for the collections.

Start by tracking the movies collection. Click on the Track button next to the movies collection.

In this step, you’ll need to indicate to Hasura the structure of the JSON object so that Hasura can inspect it and generate a GraphQL schema for it.

Insert the following JSON as input:

{
  "_id": {
    "$oid": "573a1390f29313caabcd42e8"
  },
  "plot": "A group of bandits stage a brazen train hold-up, only to find a determined posse hot on their heels.",
  "genres": [
    "Short",
    "Western"
  ],
  "runtime": {
    "$numberInt": "11"
  },
  "cast": [
    "A.C. Abadie",
    "Gilbert M. 'Broncho Billy' Anderson",
    "George Barnes",
    "Justus D. Barnes"
  ],
  "poster": "https://m.media-amazon.com/images/M/MV5BMTU3NjE5NzYtYTYyNS00MDVmLWIwYjgtMmYwYWIxZDYyNzU2XkEyXkFqcGdeQXVyNzQzNzQxNzI@._V1_SY1000_SX677_AL_.jpg",
  "title": "The Great Train Robbery",
  "fullplot": "Among the earliest existing films in American cinema - notable as the first film that presented a narrative story to tell - it depicts a group of cowboy outlaws who hold up a train and rob the passengers. They are then pursued by a Sheriff's posse. Several scenes have color included - all hand tinted.",
  "languages": [
    "English"
  ],
  "released": {
    "$date": {
      "$numberLong": "-2085523200000"
    }
  },
  "directors": [
    "Edwin S. Porter"
  ],
  "rated": "TV-G",
  "awards": {
    "wins": {
      "$numberInt": "1"
    },
    "nominations": {
      "$numberInt": "0"
    },
    "text": "1 win."
  },
  "lastupdated": "2015-08-13 00:27:59.177000000",
  "year": {
    "$numberInt": "1903"
  },
  "imdb": {
    "rating": {
      "$numberDouble": "7.4"
    },
    "votes": {
      "$numberInt": "9847"
    },
    "id": {
      "$numberInt": "439"
    }
  },
  "countries": [
    "USA"
  ],
  "type": "movie",
  "tomatoes": {
    "viewer": {
      "rating": {
        "$numberDouble": "3.7"
      },
      "numReviews": {
        "$numberInt": "2559"
      },
      "meter": {
        "$numberInt": "75"
      }
    },
    "fresh": {
      "$numberInt": "6"
    },
    "critic": {
      "rating": {
        "$numberDouble": "7.6"
      },
      "numReviews": {
        "$numberInt": "6"
      },
      "meter": {
        "$numberInt": "100"
      }
    },
    "rotten": {
      "$numberInt": "0"
    },
    "lastUpdated": {
      "$date": {
        "$numberLong": "1439061370000"
      }
    }
  },
  "num_mflix_comments": {
    "$numberInt": "0"
  }
}

Alternatively, if you want to copy these objects from your Mongo collections directly, head to the Collections tab under the Database section.

Click on the Validate button to validate the JSON document. In the next step, you will see the models derived from this document. Finally, click on the Track Collection button.

Step 6: Try out GraphQL queries

Once you track the collection, you should navigate to the API Explorer page on the Hasura Console to start trying out some GraphQL queries. Execute the following GraphQL query inside the GraphQL interface.

query {
  movies (limit: 10, order_by: { released: desc }) {
    _id
    title
    released
    imdb {
      rating {
        numberDouble
      }
    }
  }
}

We are trying to fetch 10 movies, sorted by released, descending. You will get a JSON response on the right as you execute the query by clicking the play button.

And voilà! A GraphQL API for the movies collection is now tested and ready for consumption. Play around with different queries as you see them on the Explorer tab on the left sidebar. You can repeat this for tracking more collections like comments, users, theaters, etc., and get APIs generated for all of them.

How is the GraphQL API highly performant?

Hasura's instant generation of the GraphQL API for collections significantly minimizes the need for boilerplate code, which would otherwise be required in the form of GraphQL resolvers on any server.

Ensuring that both the database and the API reside in the same region mitigates latency concerns. However, let's delve deeper into the mechanics of query execution behind the scenes. It essentially revolves around these key factors:

1: Database pushdown with query optimization

Hasura operates as a compiler that receives a GraphQL query, enriches it with predicates as part of the query, and then delegates the query with projection, relationships, and authorization rules to the database to handle the workload. This approach circumvents server-side data processing and capitalizes on the database's capabilities to achieve high efficiency and performance.

Given GraphQL's inherent capability for clients to specify their desired data, it becomes imperative to retrieve only the exact fields requested by the client. Hasura achieves this by compiling the query with projection. In the absence of Hasura, a typical query might be suboptimal, resulting in fetching unnecessary data (more data than required).

2: Usage of aggregation pipelines

Let’s analyze the query that is generated by Hasura. For the example, GraphQL query that we used above, click on the Analyze button on the GraphiQL section of the API Explorer page.

You’ll see that the query execution plan looks like this:

{
  "aggregate": "movies",
  "pipeline": [
    {
      "$sort": {
        "released": -1
      }
    },
    {
      "$limit": 10
    },
    {
      "$replaceWith": {
        "released": {
          "$dateToString": {
            "date": "$released"
          }
        },
        "_id": "$_id",
        "imdb": {
          "$cond": {
            "if": "$imdb",
            "then": {
              "rating": {
                "$cond": {
                  "if": "$imdb.rating",
                  "then": {
                    "numberDouble": "$imdb.rating.numberDouble"
                  },
                  "else": null
                }
              }
            },
            "else": null
          }
        },
        "title": "$title"
      }
    }
  ],
  "cursor": {}
}

You can see the usage of aggregation pipelines for high performance.
Iterating on the API with updates to collections
Updating the structure of a document in a collection is a straightforward process with Hasura. Simply adjust the Hasura metadata to include or exclude the modified fields. The schema's flexibility allows you to update the logical model to incorporate API changes seamlessly. No database migrations are necessary; — just add or remove fields from the metadata to reflect in the API.

Summary

The integration of MongoDB with Hasura's GraphQL Engine introduces a heightened level of efficiency and scalability for developers. Harnessing Hasura's ability to create a unified GraphQL API from varied data sources, developers can swiftly expose MongoDB data through a secure, high-performance, and extensively customizable GraphQL API.

Resources to learn more about the integration.

How to Build a Supergraph using Snowflake, Neon PostgreSQL, and Hasura in Five Steps

Praveen Durairaju — Thu, 20 Jun 2024 20:17:00 +0000

By combining Hasura Cloud, Snowflake DB, and PostgreSQL on Neon, you can create a powerful supergraph backend to handle complex data tasks such as joining data across multiple data sources and filtering data on model relations. It's a supergraph framework with modular, unified layers that is continuously evolving and deployed by many companies worldwide.

This tutorial will guide you through the creation of an application backend that leverages the powerful features of Snowflake and PostgreSQL databases. I will show how to integrate tables from both Snowflake and PostgreSQL into your supergraphs, allowing you to perform sophisticated, nested queries that connect models from diverse databases. This approach not only increases your backend's capabilities but also streamlines the data handling process for more complex data relationship management across different sources.

1. Setting up Hasura Cloud

Start with Hasura Cloud to quickly create GraphQL APIs.

Sign up for a free Hasura Cloud account.
Create a new project and connect it to your version control system (e.g., GitHub).
Define your data model using Hasura's metadata.
Run some exciting queries

2. Integrating Snowflake DB

Snowflake is a cloud-based data warehousing platform that seamlessly integrates with Hasura Cloud. To integrate Snowflake:

Obtain your Snowflake credentials (account, username, password).

In Hasura Cloud, navigate to the "Data" tab and add a new data source.
Select "Snowflake" and input your credentials.
“Import all tables” to add all the tables as models to the supergraph

3. Incorporate PostgreSQL on Neon

Neon is a managed platform for PostgreSQL databases. To incorporate PostgreSQL on Neon into your supergraph backend:

Obtain the connection details for your Neon PostgreSQL database.
In Hasura Cloud, add another data source, but this time, select "Neon Database" and authorize the Neon database connection details.

Add the models and relationships you want to track in the data tab.

4. Executing individual queries

Now that you have Snowflake and PostgreSQL on Neon integrated into your Hasura Cloud project, you can execute queries individually.

Querying Snowflake

To query data from Snowflake, you can use Hasura's GraphQL API:

query MyQuery {
  SNOWFLAKETABLE {
    COLUMN1
    COLUMN2
  }
}

Replace snowflakeTable, column1, and column2 with your Snowflake table and columns.

Querying PostgreSQL on Neon

Similarly, to query data from your Neon PostgreSQL database:

query MyQuery {
  neontable {
    column1
    column2
    column3
  }
}

Replace neonTable, column1, and column2 with your Neon table and columns.

5. Nested queries for complex data retrieval

GraphQL has the ability to handle complex data retrieval through nested queries. Here’s an example:

query {
  getUser(userId: 123) {
    username
    email
    posts {
      title
      content
    }
  }
}

In this query:

We retrieve user details by their ID from either Snowflake or PostgreSQL.
Then, we fetch the user's posts with their titles and content.

By defining appropriate relationships and foreign keys in Hasura's metadata for both Snowflake and PostgreSQL, you can perform nested queries like the one above, aggregating data from multiple sources into a single response.

Conclusion

Continue to explore and experiment with Hasura Cloud, Snowflake DB, and PostgreSQL on Neon. Discover how to efficiently integrate multiple data sources and execute both individual and nested queries. This will increase performance and scalability across a wide range of applications.

The Learning Path to GraphQL for Fullstack Developers

Praveen Durairaju — Thu, 28 Oct 2021 15:25:24 +0000

GraphQL has been around for 6 years now and has really empowered frontend and fullstack developers with the ability to build backends easily. With tools like Hasura, developers focus only on writing custom logic code specific to the app, taking away the repetitive CRUD APIs.

Hasura gives you instant GraphQL and REST APIs on all your data. It sits in between your application and the data sources to give you the goodness of GraphQL, Authorization and a slew of security and monitoring features. The core Hasura GraphQL Engine is open source and we have a Cloud offering for managing infra and advanced production ready features.

We at Hasura, along with the community have created a series of open source tutorials starting from GraphQL Basics, Hasura Basics to full fledged frontend tutorials in various frameworks. You name it, we have it :)

Begin your journey with GraphQL Basics

If you are completely new to GraphQL, we recommend taking our Introduction to GraphQL course. This will get you from Zero to GraphQL in less than an hour.

The key to learning GraphQL is to understand that it is just a query language and popular implementations on the client and server leverage existing JSON standards for requests and responses over HTTP.

Once you are familiar with this concept, it will become easier to grok the benefits of GraphQL. The Intro to GraphQL tutorial covers some fundamental concepts like

The three most common things you will encounter with GraphQL are

Queries
Mutations
Subscriptions

This along with the type system makes GraphQL the powerful self-serve API that everyone can use intuitively.

You will also understand the different approaches one can take while writing a GraphQL Server. Finally you will learn how GraphQL Clients make data fetching, consuming realtime subscriptions really easy.

Setup the backend with Hasura

Once you have understood what GraphQL is and the core concepts around it, you can progress to the easiest step in the journey. i.e Setting up a GraphQL API with Hasura.

We have put together a concise tutorial for Hasura Basics to create a production ready GraphQL API from scratch without writing much code. You will be able to use the power of database, set up Authorization rules for security and write custom business logic code specific to a realtime use case.

Once you go over this Hands-on tutorial, which should take about ~30 mins to an hour, you will be able to start integrating the GraphQL API with any frontend app.

Optional: Database Ninja

Hasura connects to a database (either PostgreSQL, MySQL or MS SQL etc) to give you a GraphQL API. Now if you are a frontend developer who is new to the database ecosystem, then you are covered with our database series.

The database tutorials will teach you core concepts around data modeling with examples of SQL statements and key fundamentals to know just enough to deploy an app in production.

Integrate GraphQL backend with frontend

Once you are familiar with GraphQL and setting up a backend with Hasura, you can start trying out the real power of GraphQL in the frontend app. In this frontend series, you will learn how modern GraphQL client side tooling can be integrated with a GraphQL backend like Hasura.

There are tutorials available in most popular frontend frameworks and mobile first languages.

The highlights of this series are the examples around consuming realtime subscriptions and patterns around handling data in cache.

Join our GraphQL Learning Circles

Starting from November 2021, We’re going to host GraphQL Learning Circles to go over the various tutorials that we and the GraphQL community have created and contributed to on a weekly basis. If you’d like to host a GraphQL Learning Circle reach out to us on discord.

Do subscribe us on YouTube to get notified about the schedule for these live tutorials.

We would love to hear what you would like to see on the Hasura Learn portal. We are constantly updating the tutorials to keep in pace with industry standard language and framework versions and best practices.

Do check it out and spread the love :)

Migrate from Graphcool to Hasura

Praveen Durairaju — Sat, 09 May 2020 12:29:12 +0000

Graph.cool will be sunsetted July 1, 2020. If you have an existing project, it is time to migrate off from their platform to have enough leeway for testing and going production.

I have been helping a few folks migrate from Graph.cool to Hasura and decided to put together a rough migration path.
Hasura is an open source engine that connects to your databases & microservices and auto-generates a production-ready GraphQL backend.

Pre-requisites:

We will be using docker to run some containers (MySQL, Postgres and Hasura). If you don't have docker on your machine yet, it is time to set up. Read their official docs

Note: This guide is not comprehensive and some steps require manual intervention depending on your Graph.cool project. Feel free to ask any queries in the comments. You can also DM me on Twitter. I will be happy to help you out :)

But here's roughly what you need to follow to get going.

Step 1: Export data from Graph.cool

Export your Graph.cool data using their export tool. This will give a MySQL binary dump of your current Graphcool data.

Step 2: Set up an intermediary MySQL server

We need to set up a MySQL server as an intermediary step in order to migrate data from Graph.cool to Postgres.

Step 2.1: Start MySQL with Docker

docker run --name graphcool-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -p 3306:3306 -d mysql:latest --default-authentication-plugin=mysql_native_password

Replace the password (my-secret-pw) as required.

Step 2.2: Connect to MySQL via mysql CLI

mysql --user=root --password=my-secret-pw --host=<host>

Replace the host and password as required.

Step 2.3: Create a database in MySQL

create database public;

Step 2.4: Import data

Import Graph.cool's MySQL export into your local MySQL instance:

mysql --user=root --password=my-secret-pw --host=<host> public --binary-mode=1 < <pathtomysqlexport>

Replace host and pathtomysqlexport as required. Your data should now be present in the MySQL database.

Step 3: Migrate data to Hasura

Since MySQL is now set up with all the data from Graph.cool, we need to create a Hasura and Postgres instance, and to import the data to the same.

Step 3.1: Set up Hasura

Refer to the Getting started guide to set up Hasura using docker-compose.

Step 3.2: Import data into Postgres

We will use pgloader to migrate from MySQL to Postgres. Refer to their installation guide for setting this up.

Once you have installed, execute the following command:

pgloader mysql://root:my-secret-pw@<host>/public postgresql://postgres:postgrespassword@<host>:5432/postgres

Replace <host> and mysql password (my-secret-pw) as required.

Your data should now be present in the Postgres database.

Step 3.3: Connect Hasura to Postgres

Once the dataset is migrated to Postgres, Hasura should be able to track tables and relationships.

Note: If you have enums in your Graph.cool project, check out Enums in Hasura, since they're handled differently in Hasura and you would need to change the data structure a bit.

Step 4: Migrate structure & functionality

After migrating the data to Hasura, there is some manual work involved in migrating the structure and functionality of your Graph.cool project.

Step 4.1: Restructure connection tables

You can rename tables/columns to match your client-side queries as required. Do note that, for every one-to-one relationship, Graph.cool would have created a connection table to link them. This would require a bit of manual work to restructure. Currently, there is no automation available for this step. Carefully review the connection tables and make the necessary changes.

Read up more about Relationships in Hasura

Step 4.2: Migrate functions

In case you have functions in Graph.cool, Hasura has an equivalent feature called Event Triggers. Migrating this involves taking your code and deploying it on a different platform. It could be a serverless function or all the functions can be combined into a monolith Node.js server. The choice is up to you.

Do note that for event triggers, the payload that Hasura sends might be different, and you might have to change the way the request body parameters are handled in your function code.

Step 4.3: Migrate auth

There are two ways of authenticating users in Graph.cool:

Using Auth0
Using email-password auth.

If you were using Auth0 with Graph.cool, the migration should be fairly straightforward. You can configure Hasura with Auth0 easily by following the Auth0 guide.

In case you are using email-password auth, Graph.cool generates mutations for

creating a user

createUser(authProvider: { email: { email, password } })

signinUser(email: { email, password })

You will need to implement these custom mutations using Hasura Actions.
Refer to this example for a custom signup mutation. You can modify this to include login functionality.

Step 4.4: Migrate permissions

The CRUD permissions in Graph.cool can be manually migrated to Hasura's permission system. You can define roles in Hasura and configure permissions declaratively for all the CRUD operations.
Refer to authorization for configuring Hasura permissions.

Community Tooling for File Storage

Nhost has a community maintained solution hasura-backend-plus for handling Files on Cloud providers like S3 in case you are looking for a way to migrate Files from Graph.cool. They also have an Auth solution that can be integrated with Hasura :)

Subscriptions

Hasura gives you realtime APIs out of the box. All your Postgres tables can be subscribed from the client using GraphQL Subscriptions.

I hope this guide gives an indication of the steps involved. In case you are stuck with any of the steps, do ping me :)

Hasura has an active and a helpful discord community. Do join the discord server as well and post your queries.

Approaches to add dynamic content to statically generated sites (JAMStack)

Praveen Durairaju — Wed, 16 Oct 2019 12:14:38 +0000

TL;DR

The different approaches to add dynamic content to statically generated sites with JAMStack.

JAMStack Constraints
Types of Content
- User specific: Public / Auth protected
- Frequency of updates: Infrequent / Frequent
- Interactivity: Non-interactive / Interactive
Source data during build phase
Static pages hydrated on client
Separate Static and Dynamic pages
Caveats
Summary

JAMStack Constraints

JAMStack is an emerging architecture for web apps which aims to decouple frontend and backend dev teams. Read more about it here. The architecture allows for a performance and operational benefit by imposing a few key constraints on how you build your UI.

These are the key constraints:

Pre-built markup/UI

Markup is pre-built to ensure good performance and SEO. UI should be pre-built and deployed as HTML files instead of getting rendered on the client (like what vanilla SPAs do).

No server side code that deals with UI

No server side code implies that the UI developer deploys their code as an HTML/CSS bundle, focussing on rendering the frontend. They needn't do server-side templating / server-side rendering.

As you can imagine, these two constraints give the UI team great ownership in being able to deploy and own their code (no server-side complexity). There is no server side templating like how it's typically done in Django/Rails application and they can assume content will be injected into HTML from a data source.

JAMStack is great for static sites or static site generators, but the key question is, what about "dynamic" sites or apps?

Types of Content

Before we try out these approaches in-depth, let's walkthrough the different types of content to see which approach works for what. The content for a webpage comes from a data source, typically a database. This data could change frequently based on user interactions. There could be multiple data sources to get content from. For example, a blog can have content coming from a database and user information coming from an auth provider. Broadly content types can be classified to be one or more of the following:

User specific (public or private)

In case of static web pages, the content served would be the same for all users. But what if, depending on the user who is viewing the page the content served needs to be different? Users of the site can also generate personal content and how do you build all those static pages pre-deployment time?

The answer is simple. You can't build the markup ahead for user specific content. This gives us the classification based on whether the content is publicly accessible or protected. Content on a webpage can be public, accessible to all or protected behind auth and will be different for different users.

Frequency of updates (frequent / infrequent)

Another classification of content would be to base it off on whether the content changes and if so, how often. If content changes frequently, then it needs a dynamic runtime to take over from the pre-built markup that was generated.
Let's say there's page content that you want to change and you want to reflect the changes immediately to your users. With pre-built markup, this doesn't happen realtime and there is a delay with re-building and deploying. Content on a webpage can change frequently, realtime or doesn't change that often.

Interactivity (interactive / non-interactive)

Users interacting with the page in the form of search, comments, forms, e-commerce checkout, payments etc are dynamic and a pure static web page doesn't scale for these kind of interactions. And hence the final classification based on interactions. Content on a webpage can be either interactive or non interactive.

Choosing the right approach for your dynamic content

Let's see how we can apply different approaches to handle different types of content and decide which ones are more suitable for a given use case. Go over the below flow to see which approach is applicable for your use case.

We'll look at different approaches to handle dynamic content and how it can be implemented to make a JAMStack (pre-built markup) site dynamic.

Approach #1: Source data during build phase

The simplest way to make JAMStack Dynamic is to source dynamic content at build time. The content can come from any data source. Data sources can be markdown (suited for blogs/docs), JSON/YAML and APIs, including third party ones. The API(s) would be responsible for fetching content from a database or a datastore and thus makes it a powerful way to build sites with dynamic content.

The data sources are compiled to HTML, typically using a static site generator. During the build phase, these generators traverse through every path of the app and compile flat HTML files out of it. It uses specified data sources to compile the HTML.

Architecture

With git automation, git push should trigger an automated build which is then deployed to cloud providers. Add a CDN for caching and an app with decent traffic should run easily.

What is this architecture best suited for?

Let's say you have some data which is coming from the database (accessed using APIs) but is not updated frequently. With this architecture, you can cache content which is infrequently updated, and only trigger builds for the content that changes. Do note that the data still comes from a data source like a database/markdown during the build phase and hence any changes will reflect eventually.

Trying it out with Gatsby and Hasura

Hasura fits into Dynamic JAMStack with its unified GraphQL API sourced into Gatsby. Here's an example of using Gatsby with Hasura with dynamic content. Hasura is being used as a Headless CMS in this example and the amount of backend code written is significantly reduced.

Approach #2: Static pages hydrated on client

As you would imagine, just having pre-built content may not suffice for many apps. In this approach, we will look at how to fetch data at both build and run time for any page. This is achieved using a process called hydration, that allows static markup to be sent to the client which further becomes a dynamic app with the ability to manipulate the DOM. The benefit is obvious; users see a fully rendered page and then it becomes interactive like an SPA.

Now let's look at various possibilities of dynamic content on the client. You have a site that requires client side functionalities such as search, comments, handling forms and e-commerce actions. Do note that some of them could be coupled with Authentication/Authorization as well.

To handle these client side interactions, what we need is a pre-rendered static site + a dynamic runtime, maintaining the performance benefits and major parts of SEO.

Architecture

With the markup rendered on the client, we would like the client to take over to make it interactive. This should be possible with hydration.

Hydration

Hydration is a concept where the client expects the generated markup on both client and server to be identical. It is a process during which the framework (like react/vue) takes over the static HTML sent by the server and turns it DOM that can be manipulated and react to client-side data changes. In short, this makes sure that the client is ready for dynamic content without reloading.

All pages should work by default without JavaScript being enabled on the browser and client side rendering is just a progressive enhancement.

Interactions -> Serverless Functions

On the client side, the user would typically do auth (login/logout), interactive actions (search, comments) etc. The user interactions can be forwarded to serverless functions which can internally perform business logic to handle state of the app.

User interactivity can be lazy loaded on the client. Consider the example of this blog. The Disqus comments are loaded on the client where as the article was pre-rendered during build phase.

Realtime

Feed based UIs could require data to come in realtime. How do we update content on the UI realtime? Websockets FTW! A websocket connection can be setup to listen for notifications. Anytime new data comes in, the client is notified about the data update.

If you have access to a Realtime GraphQL API, it should be as simple as setting up websockets on the app to connect and fetch live data. Obviously this API needs to support Auth, in case it's required. Here's a reference video tutorial for how it's done with Hasura.

Asynchronous calls

On the client, you can make asynchronous calls to external APIs for fetching/mutating data for UI views which are not user blocking. The APIs can be serverless functions.

Trying it out with Gatsby and Hasura

Here's an example of using Gatsby with Hasura. Markup is hydrated on the client and some data is fetched only during runtime, assuming its dynamic.

Approach #3: Separate Static and Dynamic Pages

By now, you would have realised that static data is important for improved page load time and time to interactive. But what about pages which cannot be pre-built at all? Imagine a user profile page or a search results page. The content of these pages cannot be determined during build phase.

Some pages of the app are completely static, while some are completely dynamic. We can separate out the static and dynamic pages neatly, so that static pages get their performance boost, while dynamic pages are completely loaded on the client, behaving like an SPA.

Let's consider the example of an e-commerce product page to understand this better. There are some routes which are primarily static and doesn't have dynamic interactions on the client.

In an e-commerce site, pages can be pre-built for homepage, listing page, product page etc and can be rendered on the server. But user profile, search results, cart or payment pages cannot be pre-built. They are completely loaded on the client. Usually these pages are also behind Auth.

Completely Static Pages -> Sourced during build phase. Ideal for performance and SEO.

Completely Dynamic Pages -> Loaded on client side on demand. Interactive for users. Distributed the load to client. Protected routes are used to block access to users.

In the above example, product details would be pre-rendered markup where as ADD TO CART would be dynamic interaction on the client and the Cart page itself would be protected by auth, being completely dynamic.

Caveats

The approaches mentioned above come with a few caveats. Although they are not blockers, it's good to know them to know where this works and where it doesn't.

Completely Dynamic Apps

What about apps which are completely protected behind auth? Hasura Console is a good example of that; In fact all admin dashboards are protected behind Auth. Content can be different for users who have logged in. Obviously these pages cannot be built during compile time.

There is a way to handle this. This approach requires you to build your app as an SPA (Single Page Application) where everything is loaded on the client or SSR (Server Side Rendering) where the server compiles HTML on every request. I didn't mention this approach earlier because this doesn't have any pre-built markup and is not the scope of this post 😃

Updating Content

If data in the database changes, the app will not show the current data till it's rebuilt. So the option is to either trigger a rebuild whenever there is a data change or take advantage of hydration to update data dynamically on the client once the page is loaded.

What about large sites?

Build time increases with fairly large sites. Assume a content site with over thousands of posts. Rebuilding all the pages would be very slow. Deployments need to be instant. So how does one perform quick deployments?

Incremental builds is the way forward. Here’s a good read from Netlify. The idea is to cache the older content which doesn't require changing and rebuild only the pages which have been added recently so that deployments are instant. This solution may not exist for all frameworks today.

Summary

JAMStack is a neat architecture to highlight the benefits of static sites that we were building a few years ago (and continue to). The idea behind Dynamic JAMStack is to get pre-built markup to the client as much as possible and do progressive enhancement on the client via Hydration to open up a lot of possibilities.

Coupled with modern frontend frameworks and headless CMS, these static sites can become truly dynamic bringing in a whole lot of benefits and flexibility to build powerful apps. This way we build sites for performance.

Of course these approaches may not be suitable for all types of apps. There are still use cases which requires an app to be completely SPA or completely SSR for obvious reasons and they continue to work well in their current architecture.

Here are some good reads:

Build and Deploy Realtime Svelte 3 Apps Using GraphQL

Praveen Durairaju — Thu, 23 May 2019 13:56:38 +0000

What is Svelte?

Svelte is a component framework that compiles components at build step (unlike React/Vue) into highly efficient imperative code that updates the DOM.

Svelte gives a single bundle.js that can be referenced in the app's HTML which doesn't contain any framework specific dependencies (magically disappearing framework was their tagline before). The bundles are usually smaller than other frameworks with greater emphasis on accessbility.

This also means that there is no virtual DOM and no extra work like virtual DOM diffing and it looks like there are performance benefits to it. State management is made easy since its just javascript variables and updating them would re-render the component by updating the DOM directly (truly reactive)

You will also see in the sample app that there's less boilerplate code than other frameworks to achieve the same functionality. Svelte released their stable version 3 last month and here's an interesting blog written by Rich Harris if you would like to learn some details.

Alright! Now let's see how a simple realtime app can be made using Svelte and GraphQL. To get started, we will deploy Hasura.

Deploy Hasura

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 webhooks on database changes.

Follow the instructions in the readme to deploy Hasura and create the tables author and article required for the app. Note the Heroku URL for GraphQL Endpoint. You will be configuring this in the app.

Clone and Run App

The demo app walks you through to build a simple realtime app, listing all authors and articles.

In this example, we will look at building a simple app to

Fetch articles and authors using GraphQL Queries,
Adding an author using GraphQL Mutations and
Demonstrate realtime capabilities using GraphQL Subscriptions by updating authors list in realtime.

To integrate GraphQL into Svelte, we will make use of svelte-apollo module to perform queries.

You can clone and run the app for the demo.

$ git clone git@github.com:hasura/graphql-engine.git
$ cd graphql-engine/community/sample-apps/svelte-apollo
$ npm install

After installation, you will have to configure the GraphQL endpoint that you got above after deploying Hasura on Heroku.

Open src/apollo.js and configure the endpoint.

Now run the app using

$ npm run dev

Note: This app was forked off from the standard template and svelte-apollo dependency was added to integrate GraphQL
Here's an example of a Svelte component making a GraphQL query to fetch list of articles:

Here, we are importing the query method from svelte-apollo and passing in the client and the GraphQL query to fetch the list of articles. There's also the restore API to restore a previously executed query into Apollo Cache. The previous query came through preload method called during app initialisation.

And subscriptions are pretty easy as well:

If you looked at it carefully, this would be slightly similar to the React hooks style of implementation in the sense of less boilerplate code.

Bundle using Rollup

Svelte comes with default Rollup bundling and configuring Rollup is also fairly easy. When you run the command npm run build , rollup generates a bundle.js, which is referenced in index.html and bundle.js doesn't contain any framework specific dependencies like React or Vue, since Svelte bundles at compile time.

Deployment

Deploying a Svelte app is as simple as deploying a simple static HTML app with javascript and css files.
Let's use now-cli to deploy the app. Install the now cli, if you don't have already.

npm install -g now

And from within your project folder, execute the following command:

now

This will deploy our svelte 3 app on Now using the configuration available in now.json. Obviously it can be deployed on popular providers like Netlify, Heroku etc.

Final Thoughts

Svelte comes with least learning curve despite deviating from JSX style familiar to React developers and i would personally compare the syntax to Vue, as in you focus on writing HTML separately.

If you are familiar with React/Vue and other virtual DOM based frameworks, you can try out Svelte for less boilerplate code and potential performance benefits. Of course GraphQL integration is pretty easy and you get all the benefits with lesser effort.

There's also an SSR framework for Svelte named Sapper, if you are concerned about SEO.

Take the demo for a spin and let us know what you think.

Building a Progressive Todo Web App with Vuetify, Vuex and GraphQL

Praveen Durairaju — Tue, 26 Mar 2019 10:38:07 +0000

TL;DR

Build a progressive todo app with Vuetify, Vuex, VueApollo and integrate GraphQL APIs using Hasura GraphQL Engine.

Instant setup. App Source Code 👉 vuetify-vuex-todo-graphql

Tech Stack

This progressive web app uses the following frameworks/servers

Vue.js with Vuetify for Material Design UI, Vuex for state management, VueApollo for making GraphQL queries
Hasura GraphQL Engine to get instant GraphQL APIs over Postgres

Vuetify Framework

Vuetify is a semantic component framework for Vue. It is built according to Google's Material Design Spec and has intuitive properties without complex classes and markup.

In this app, we make use of Vuetify components like VGrid, VCard, VList, VTextField, VBtn among a bunch of available reusable components.

The progressive todo web app is a fork of davidgaroro/vuetify-todo-pwa which uses

Vuetify for the TodoMVC UI with material design
Vuex for state management

Here's how the todo app looks like with Vuetify's material design components:

We added vue-apollo to this app and configured ApolloClient to make GraphQL queries for storing and managing the todos in the database. We will use Hasura to get instant GraphQL APIs.

Hasura + vue-apollo

We will integrate Hasura GraphQL APIs with this todo app. Refer the github link to deploy Hasura and create the todos table.

Once we have Hasura deployed, we can configure the frontend to make GraphQL queries. We add all modules required to configure ApolloClient.

npm install --save vue-apollo graphql apollo-client apollo-link apollo-link-http apollo-cache-inmemory graphql-tag

Note: You can also use apollo-boost, if you don't need fine grained control over configuration

We define ApolloClient in src/apollo.js file in the todo app,

import Vue from 'vue'
import VueApollo from 'vue-apollo'
import { ApolloClient } from 'apollo-client'
import { HttpLink } from 'apollo-link-http'
import { InMemoryCache } from 'apollo-cache-inmemory'

const httpLink = new HttpLink({
  // You should use an absolute URL here
  uri: 'https://myapp.herokuapp.com/v1alpha1/graphql'
})

// Create the apollo client
export const apolloClient = new ApolloClient({
  link: httpLink,
  cache: new InMemoryCache(),
  connectToDevTools: true
})

const apolloProvider = new VueApollo({
  defaultClient: apolloClient
})

// Install the vue plugin
Vue.use(VueApollo)

export default apolloProvider

We need to just configure Hasura GraphQL Engine endpoint in the httpLink and import this apolloProvider in main.js and add it to the Vue instance like this:

import Vue from 'vue'
import App from './App.vue'
import router from './router'
import store from './store'
import apolloProvider from './apollo'
import './registerServiceWorker'
import './vuetify'

Vue.config.productionTip = false

new Vue({
  router,
  store,
  apolloProvider,
  render: h => h(App)
}).$mount('#app')

Once this is configured, the apolloClient can be imported and used across the app.

We define the GraphQL queries/mutations and trigger them in Vuex store.

For example, to fetch all the todos, we define a simple query to fetch todos sorted by latest id.

const todoQuery = gql`{
    todos(order_by: [{id: desc}]) {
      id
      text
      is_completed
    }
}`

and in our actions, we make this query using apolloClient and invoke the mutation handler using commit which will update the state.

const actions = {
  async fetchTodos ({ commit }) {
    const { data } = await apolloClient.query({query: todoQuery})
    commit('fetchTodos', data.todos)
  },
}

Note that we are making use of async, await which makes the syntax cleaner.

Let's define a GraphQL mutation to insert a new todo.

const todoMutation = gql`
  mutation insert_todos($text: String!) {
    insert_todos(objects: [{text: $text}]) {
      affected_rows
      returning {
        id
        text
        is_completed
      }
    }
}`

This mutation accepts a $text variable and inserts it into the todos table.

Similarly we define GraphQL mutations for adding/updating/deleting todos and we define actions to make the mutation and update the state in the Vuex store.

Progressive Web App

This todo app is a PWA and comes with boilerplate setup for

App manifest
Service worker
Workbox options - Cache Google Fonts

which can be configured to get a Lighthouse score of 100.

Todo App Source Code

I have put together the app with complete GraphQL integration so that you can get started quickly and extend it further!

Check it out on github.

Note that this app doesn't have any user authentication yet and its currently a demo to integrate GraphQL queries/mutations with Vuetify + Vuex with Hasura.

Build Responsive Cross Platform Vue Apps with Quasar Framework and GraphQL

Praveen Durairaju — Wed, 20 Mar 2019 11:48:00 +0000

TL;DR
Build responsive SPAs, SSR Apps, PWAs, Hybrid Mobile / Electron Apps using a single codebase with Quasar Framework powered by Vue.js and GraphQL APIs over postgres using Hasura GraphQL Engine.

Instant setup. Tutorial/boilerplate 👉 quasar-framework-vue-graphql

Quasar Framework

Quasar Framework is a high performance full frontend stack allowing developers to maintain a single codebase to build different types of apps (SPA, SSR, Hybdrid etc).
It is powered by Vue.js but comes with its own set of built-in web components that can be imported to quickly construct an interface for the app.

Hasura with Quasar

Hasura GraphQL fits in neatly in this workflow of building cross platform apps. All the clients(mobile app/electron app) use the same set of APIs controlled by the same set of permissions and auth and can leverage the power of Postgres. Quasar gives endless possibilities with one codebase and a common GraphQL API from Hasura adds to the easier development workflow.

Now let's see some implementation details for a simple author/article blog app:

Plugins

Quasar allows users to define app plugins which can be used to run code before the root Vue instance is instantiated.

quasar new plugin apollo

And we define the apollo plugin inside src/plugins/apollo.js and create the ApolloClient with Hasura GraphQL API Endpoint.

In this sample app, we are making use of this plugin to inject Apollo props to Vue prototype. So inside .vue files, we can make use of this.$apollo to execute any graphql specific actions.
We can configure quasar to add the new plugin by modifying quasar.conf and adding apollo in the plugins list as below:

module.exports = function (ctx) {
  return {
    // app plugins (/src/plugins)
    plugins: [
      'apollo'
    ],
  }
}

In the layouts, we have defined a layout drawer listing out the authors and a simple GraphQL query to fetch author has been used.

<script>
import { openURL } from 'quasar'
import gql from 'graphql-tag'

const authorQuery = gql`
  query {
    author {
      id
      name
    }
  }`
export default {
  name: 'MyLayout',
  data () {
    return {
      leftDrawerOpen: this.$q.platform.is.desktop
    }
  },
  methods: {
    openURL,
    fetchArticles (item) {
      this.$router.push('/author/' + item.id)
    }
  },
  apollo: {
    // Simple query that will update the 'author' vue property
    author: authorQuery
  }

}
</script>

This is still the same kind of code you would have written with Vue.js apps to make a GraphQL query with vue-apollo. But the difference is the <template> where quasar gives native-like components to build hybrid apps.

The author list is rendered on a <q-layout-drawer> and it is automatically responsive as with every quasar layout component. Quasar comes with all sorts of layout, button, form components and more that you can get you started quickly to create a native feel app.

Build Targets

Quasar requires you to specify the mode spa|ssr|pwa|cordova|electron of the app and the target cordova|electron (in case its a hybrid app). You can also specify themes like material, ios etc which will apply the styles for each component appropriately.

Build and Deploy Serverless React Apps with Next.js 8 and Zeit Now

Praveen Durairaju — Thu, 21 Feb 2019 11:39:17 +0000

TL;DR: Configure Next.js 8 serverless mode to generate lambdas for each page. Use Hasura GraphQL API as data layer. Deploy to Zeit Now. Instant setup. Tutorial/boilerplate 👉 nextjs-8-serverless

Next.js 8 landed last week with support for serverless deployment. With this release, Next.js splits an application into serverless lambdas helping improve both reliability and scalability. The "pay for what you use" model is one of the key benefits to going serverless. There are obvious other benefits like distributed points of failure and scale as you go. Out of the box support for serverless is exciting!

To quickly test this out, i had created a Next.js 8 app integrating Hasura GraphQL Engine. The app had a couple of pages; index and about. The index page renders a list of authors fetched from Hasura GraphQL. The about page renders some static text. Here are the instructions for you to get started.

Deploy Hasura

Follow the instructions in the readme to deploy Hasura and create the table author required for the app. Note the Heroku URL for GraphQL Endpoint. You will be configuring this in the app.

Clone and Run app

The demo app walks you through to build a simple app, listing all authors. You can clone and run the app for the demo.

$ git clone git@github.com:hasura/graphql-engine.git
$ cd graphql-engine/community/sample-apps/nextjs-8-serverless
$ npm install

After installation, you will have to configure the GraphQL endpoint that you got above.

Open lib/init-apollo.js and configure Hasura GraphQL Endpoint in uri
Now run the app by using the following command:

$ npm run dev

and visit http://localhost:3000 to view the app.

Enabling Serverless Mode
To enable serverless mode, we add the serverless build target in next.config.js.

module.exports = {
  target: "serverless",
};

That's it! Now build the serverless app by running the following command:

$ npm run build

The build that is generated by Next.js has a very low footprint, with the base zip size of the serverless function being 50KB. The function that is output doesn't require any other dependencies, since everything required is already bundled in. Of course, depending on the page's internal dependencies, the final size would be more than 50KB.

In the .next folder, you will see a serverless folder generated after the build. Inside that there is a pages folder, which will have outputs of lambda per page.

pages/index.js => .next/serverless/pages/index.js
pages/about.js => .next/serverless/pages/about.js

These pages can now be independently deployed onto other cloud providers.

Deploy to Now Platform

The Now Platform gives a seamless way to deploy it to the cloud with now (download): Run the following commands to deploy

$ npm install -g now
$ now

Note: Older versions of now-cli doesn't support serverless mode.

Once the deployment is successful, you will be able to navigate to pages / and /about, with each one internally being a lambda function which Now manages.
The Now Platform takes care of the routing which is available across a few regions. The lambdas are all deployed onto AWS. You can read more about available routing and regions here.

The outputs of the build process can be static files or serverless lambdas. Static files will be served directly from Zeit's edge caches, while lambdas contain code that gets executed dynamically and on-demand.

As you can see in the image below, about and index pages are lambdas. The static assets are being cached by Zeit.

Migrating from older versions

Next.js 8 maintains backward compatibility and hence for most applications, all you need to do is run:

$ npm i next@latest react@latest react-dom@latest

And set up the config in next.config.js to have the serverless build target and you should be good to go.

Final Thoughts

This is an interesting shift towards deploying web apps as serverless lambdas. Since each page of the app is a lambda, you pay only for the number of invocations and you can choose to scale high traffic pages selectively. Static assets can be cached as well, providing an affordable and scalable option from day 1.
Check out the sample app on github.

Create Nuxt.js Universal Apps using GraphQL and Postgres

Praveen Durairaju — Wed, 30 Jan 2019 14:43:45 +0000

TL;DR:

Server side render websites using Nuxt.js and GraphQL APIs over postgres using Hasura GraphQL Engine. Instant setup. Tutorial/boilerplate 👉 nuxtjs-postgres-graphql

Building universal apps is generally touted to be hard and Nuxt.js is here to solve this for Vue.js apps by being performant and modular. Hasura GraphQL Engine makes it easy to get GraphQL APIs on top of Postgres database. In this post, we will look at how these two can be integrated.

Nuxt.js

Nuxt.js gives full support for SSR apps and takes care of the common pitfalls. Being a universal app makes it more exciting; the page is server rendered and then SPA takes over. This is how it works:

Pages:

Nuxt is opinionated on the project directory structure. It will transform every .vue file inside the pages directory as a route for the application. The community has embraced the opinionated directory structure with different projects (looking at you Gatsby, Next.js) and its quite easy to get familiar with. In the boilerplate example, you can see how the pages are structured. For more information on the directory structure that Nuxt enforces, read more here.

Server side data fetching:

Nuxt community has built this apollo-module that sets up apollo client for a GraphQL endpoint. So in the index.vue page, we add the apollo snippet inside script as follows:

Here, author is a graphql query which fetches the list of authors from the database and updates the author property in vue. This GraphQL query is executed on the server and the data is available in template which allows the page to be rendered server side. The same query is then executed on the client side as well, making it universal/isomorphic. apollo-module in Nuxt accepts a clientConfig which can be used to configure endpoint, authentication and other parameters as well.

Nuxt.js + Hasura + apollo-module = Universal apps with GraphQL!

I have put together a boilerplate and tutorial so that you can get started quickly!

Check it out on github.

awesome-angular-graphql: A curated collection of resources for Angular and GraphQL

Praveen Durairaju — Mon, 26 Nov 2018 09:37:34 +0000

This is a compilation of resources, clients and tools that make working with GraphQL and Angular awesome.

https://github.com/hasura/awesome-angular-graphql

Feel free to suggest more articles/videos/tools.

Setting up a production ready realtime GraphQL backend in just a few minutes

Praveen Durairaju — Tue, 20 Nov 2018 15:43:28 +0000

Since Facebook announced GraphQL three years ago, GraphQL popularity has grown by leaps and bounds. In the 2018 state of javascript survey, 83% of JS developers had either used GraphQL or wanted to learn it, and it is well on its way to becoming a megatrend.

npm trends for GraphQL

Adopting GraphQL can result in a significant increase in feature velocity, and any organization looking at new product development or re-architecting their existing products should seriously evaluate GraphQL and the benefits that it brings.

Getting started with GraphQL quickly

At Hasura, we have just released the DIY Realtime GraphQL BaaS. It uses the Hasura GraphQL Engine, Auth0 and DigitalOcean, to help you setup a production ready GraphQL backend in a few minutes - sort of like Firebase, but for realtime GraphQL, over Postgres, on your own infrastructure. It offers you the ease of use of a BaaS (set up in a few minutes), while allowing you to retain flexibility and control going forward.

Here’s how you can set it up:

1) Deploy the Hasura GraphQL engine on DigitalOcean using the one-click deploy. It comes with a Postgres database and Caddy webserver for easy and automatic HTTPS using Let’s Encrypt.

Deploy Hasura GraphQL on DigitalOcean

2) Create your schema using the Hasura console. The Hasura GraphQL Engine will give you instant GraphQL APIs, for queries, mutations and subscriptions.

Create schema

3) Configure Auth0 rules and callback URLs, and integrate it with Hasura.

Configure access control rules

And that’s it! You have a full-fledged backend with GraphQL APIs and Authentication/authorization on managed infrastructure. On the 5$ machine, you should be able to handle thousands of users. Of course, if you want to handle more users, you can just upgrade the underlying infra.

We have used DigitalOcean and Auth0 for this example for their ease of use, you can use any other infrastructure provider or authentication provider.

Next steps

Once you have the BaaS setup, there are tons of other cool things you can do as you build complex applications, and take them to production:

Write custom backend code or business logic and use schema stitching to merge with Hasura.
Manage postgres migrations.
Trigger webhooks on Database events to integrate with serverless functions.
Set up logging and monitoring with DataDog and Honeycomb

If you get stuck somewhere or you have some questions, feel free to talk to us on our Discord.

Full disclosure: I am an engineer working at Hasura.