DEV Community: Patryk Jeziorowski

Blazingly fast Preview Environments for NextJS, NodeJS, and MongoDB on AWS

Patryk Jeziorowski — Wed, 15 Dec 2021 10:00:59 +0000

Introduction

Have you ever dreamed of deploying your applications on the cloud without any hassle? Imagine a platform where all you need to do is to sign in with your AWS credentials, and automagically the platform does all the hard work of configuration of the cloud for you, and, on top of that, provides some extra features that do not exist out of the box anywhere else.

Qovery is this platform - not only does it allow you to deploy your infrastructure and applications on your own cloud account, but also provides extra cool features, one of which we will see in this article.

Don't take our words for granted - 14000 developers from more than 100 countries use Qovery to deploy their apps on AWS.

Preview Environments

Imagine working on a new feature. You're dealing with a full-stack application - you have a frontend, backend, and a database. You introduce a change to your backend app - how do you test all of it? It would be great if there was a service that could deploy everything for you so you can test your changes quickly and in separation with all the components...

Qovery Preview Environments are designed to help you with exactly this.

It not only deploys the app you changed but all other related applications and databases as well in the cloud so that you can test your new features and collaborate with reviewers of your code.

Preview environments feature is available on other platforms as well. Vercel and Netlify allows you to test your changes before merging code into production. It’s perfect for single frontend applications, but the concept of Preview Environments on Qovery goes far beyond this.

Qovery is able not only to create a preview environment for your frontend, but also for the backend and databases - the whole stack is supported. Running a set of backend microservices? No worries, Qovery got you covered. All services will be replicated in the new environment.

Preview environments benefits

Time-saving - You don't have to set up a fresh environment to test changes in isolation - Qovery does it all for you
Productivity - Faster changes, quicker review, better feedback loop - the productivity and quality of your application increases dramatically
Better tests - It's best to test apps in isolation, but it's almost impossible with a complicated stack if you have to prepare the testing environment manually - Qovery does it all "automagically" for you
Independence - Each environment is completely separate, meaning more people can work flawlessly on the project, testing the changes they introduce in parallel, not blocking each other
Deliver quickly - Faster feedback loop, independent developers, fewer bugs, meaning the product is delivered more quickly
Reduce friction - Waiting for others to test your changes is frustrating - with preview envs everyone has his own testing environment

Demo

AWS Infrastructure

Before we start with the deployments, we need to have our AWS infrastructure ready and deployed. It can be done as simply as by providing credentials to your cloud account, you can see how to configure the credentials in this article - https://hub.qovery.com/docs/using-qovery/configuration/cloud-service-provider/amazon-web-services/

The initial setup takes about 15 min, and your cluster is ready to host your applications.

Full Stack Application

In this example, we will use a Next.js frontend, Node.js backend, and MongoDB as a database. The app will display an image gallery with images fetched from the backend. Preview Environments feature will help us introduce a new change in the backend - moving away from a hardcoded POC list of images to a list fetched from our database.

Frontend

Our simple image gallery will look like this

To generate the application, we used npx create-next-app@latest, but the source code can be found here - https://github.com/pjeziorowski/gallery-demo/tree/master/frontend

The main changes introduced to the generated application scaffolding are:

Adding a Dockerfile

FROM node:alpine

RUN mkdir -p /usr/src
WORKDIR /usr/src

COPY . /usr/src
RUN npm install
RUN npm run build

EXPOSE 3000
CMD npm run start

Adding a query to our backend (which we will be built soon in the next steps) that fetches a list of images to display in our gallery

function useImages() {
  return useQuery("images", async () => {
    const { data } = await axios.get(
      `${apiRoot}/api/v1/images`
    );
    return data;
  });
}

Plus, we adjusted the HTML and styling for the demo purpose of showing a list of images

Backend

Our backend is the main star of the demo. In its first version, the backend is displaying a hardcoded list of images. In the next step, we will gradually expand its capabilities. It will connect to a database and fetch the list from MongoDB instead. To make sure the changes are correct, we will use Preview Environment feature before merging the pull request to our production environment

The backend was generated using Express npx express-generator --no-view, and the source code can be found here - https://github.com/pjeziorowski/gallery-demo/tree/master/backend

Changes that we introduced to the generated app scaffolding are the following:

Adding a Dockerfile

FROM node:16

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install
COPY . .

EXPOSE 8080
CMD [ "node", "src/index.js" ]

Creating a /api/v1/images endpoint that returns a hardcoded array of images

router.get('/images', (req, res) => {
    res.json([
      {
        title: 'IMG_4985.HEIC',
        size: '3.9 MB',
        source:
            'https://images.unsplash.com/photo-1582053433976-25c00369fc93?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=512&q=80',
      }
  });
});

In the next step we will improve the function to use a Mongo database instead.

Deployment

After creating a new project, let's now set up our production environment.

First, let's deploy our frontend. Click Add my first application, select a correct repository, Docker as build mode and expose port 3000. The application root path is /frontend.

Next step: add a MongoDB database - it will be used by our backend later on. You can do so by clicking on Add button in Qovery Console in Environment.

Now let's deploy our backend. Click Add → Application, pick up /backend as application root path, 8080 port, and Docker build mode.

For the future connection to DB, let's add an alias named DATABASE_URL that points to our Mongo database internal URL in our backend Environment Variable settings:

Additionally, let's create an alias called API_ROOT in our frontend application that points to our backend external URL:

This is it! Now we can deploy our production environment. After a few minutes, navigate to the frontend app, click on Open - you should be redirected to the image gallery

Enable Preview Environments

The next step to see the preview environment feature in action is to enable it for our backend application.

To do so, navigate to Environment → Settings → Preview Env and tick it for the backend app

Great! The feature is enabled. To see it in action, let's edit our code in the backend app so that the list of images is fetched from the database instead.

Testing Preview Environments

Let's make a small update of our backend - let's connect to MongoDB and fetch images from there. Here are changes to the function we could introduce to make it happen:

const databaseUrl = process.env.DATABASE_URL
    || 'mongodb://localhost:27017/test';

const imageSchema = new mongoose.Schema({
  title: String,
  size: String,
  source: String
});

mongoose.connect(databaseUrl);

router.get('/', (req, res) => {
  imageSchema.find().then((data) => {
    res.json(
      data
    )
  });
});

Let's now create a new branch in our repository and create a pull request to our production (master branch) environment. Preview Environments feature will spin up a new environment for us so that we can safely test changes we just introduced!

Now, when we display environments in our project, we will see that a new environment for the pull request is being deployed:

with all the resources we need! A database, backend, frontend - we can now test our changes in complete separation from the production without any manual setting up work:

Preview Environment Explained

The Preview Environment feature can be enabled or disabled per app. It creates a complete copy of your environment so that you can test new changes from pull requests in separation. It deploys your databases, backend, and frontend applications to a completely new environment once a pull request is opened. If you update your pull request, all new changes are also reflected in the new environment so that you can test them or fix problems during the review. What is great is that Qovery takes care of managing all environment variables for you as well, creates new aliases just as you had in your prod environment, so that everything is really tested separately and it all happens automagically. After the pull request is merged, Qovery automatically cleans up the preview environment to save your money.

Testing Preview Environments PT II

After a few minutes, your preview environment should be up and running. You can now navigate to the frontend app and click Open - in the image gallery, you will see an empty list because we don't yet have any images in the database.

You can add a few images manually by connecting to your mongo instance via CLI. The credentials can be found in the database overview:

After connecting, let's add images by executing the following:

db.createCollection("images")

db.images.insert([
       {
         title: 'IMG_4985.HEIC',
         size: '3.9 MB',
         source:
             'https://images.unsplash.com/photo-1582053433976-25c00369fc93?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=512&q=80',
       },
       {
         title: 'IMG_4985.HEIC',
         size: '3.9 MB',
         source:
             'https://images.unsplash.com/photo-1582053433976-25c00369fc93?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=512&q=80',
       },
       {
         title: 'IMG_4985.HEIC',
         size: '3.9 MB',
         source:
             'https://images.unsplash.com/photo-1582053433976-25c00369fc93?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=512&q=80',
       }
     ])

Now, after opening the frontend app in our preview environment, we will see all the images we put in the database! It looks like the feature is working well, so let's merge the PR:

What now happens is automatically after the PR merge, the preview environment is automatically cleaned up:

Great job! Thanks to Qovery Preview Environments, we managed to develop a new feature in a complete separation from our production, we tested it in a real environment deployed in the cloud, and we didn't have to spend any time preparing our environment for tests at all.

Conclusion

In the article, we quickly went through the process of creating a full-stack application with frontend, backend, and database. We enabled the Preview Environment feature to develop new features more quickly. We learned what the benefits of Preview Environments are, how to use them, and how to integrate them to day to day development workflow.

Improving Product User Experience with Data Science

Patryk Jeziorowski — Wed, 11 Aug 2021 19:40:23 +0000

The Problem

Qovery is a continuous deployment platform. Users deploy apps of all kinds, written in any language and framework they choose. The freedom users have come with a cost for the Qovery core team - the broad scope Qovery has to cover, makes it harder to make the deployment process stable and straightforward for everybody. It's easy to create a service focused on just one language or framework - supporting all of them requires considering many more factors.

The challenge we face is to make deployments as reliable and simple as possible while letting users choose any language and framework they want. We need to automate and simplify the process of finding the most commonly occurring issues to be able to prioritize and fix the most urgent problems first.

It's not possible to foresee and prepare for all the cases - the scope is just too broad. To make sure all the deployments of any kind of apps deploy and run smoothly and figure out the most common issues, we use a data-driven approach and use a few simple ML tools to simplify the process of determining the problems our users face while deploying their apps.

Embracing a scientific approach of collecting data, making measurements and taking data-driven actions is the only way to find out and fix the most common problems in building and deploying our users applications.
Error Reporting

Error Reporting

When you deploy on Qovery, our deployment Engine runs the builds and deployments of your applications. Any error encountered in the deployment pipeline is reported back to Qovery.

An example of errors we report include:

{"scope": "ENVIRONMENT", "state": "DEPLOYMENT_ERROR", "message": "\n-------------------------------------------------------------------------------\n\n MESSAGE FOR QOVERY TEAM:\n * Execution ID: 0548486d-0605-4b64-8049-24954ceec8e0-13-1625428767\n * Scope: Build platform 'beta-build' with id 'ze9e19029'\n * Rollback message: \n\n-------------------------------------------------------------------------------\n\n \u274c \u274c \u274c MESSAGE FOR THE USER \u274c \u274c \u274c\n\n \u2709\ufe0f Error message: Qovery can't build your container image beta-build (ze9e19029) with one of the following builders: heroku/buildpacks:20. Please do provide a valid Dockerfile to build your application or contact the support.\n \ud83d\udcac Need help: Look at the hint message first. If you need more assistance, you can reach the support team on Discord (https://discord.qovery.com) or on the Qovery console (https://console.qovery.com) with the integrated chat.\n \u2139\ufe0f Hint: None builders supports Your application can't be built without providing a Dockerfile\n "}

{"scope": "ENVIRONMENT", "state": "DEPLOYMENT_ERROR", "message": "\n-------------------------------------------------------------------------------\n\n MESSAGE FOR QOVERY TEAM:\n * Execution ID: d5ab51f0-94d3-4671-8dc6-77fc228f2e35-6-1627037439\n * Scope: Build platform 'beta-build' with id 'ze9e19029'\n * Rollback message: \n\n-------------------------------------------------------------------------------\n\n \u274c \u274c \u274c MESSAGE FOR THE USER \u274c \u274c \u274c\n\n \u2709\ufe0f Error message: error while building container image beta-build (ze9e19029). Error: SimpleError { kind: Command(ExitStatus(ExitStatus(256))), message: Some(\"error while executing an internal command\") }\n \ud83d\udcac Need help: Look at the hint message first. If you need more assistance, you can reach the support team on Discord (https://discord.qovery.com) or on the Qovery console (https://console.qovery.com) with the integrated chat.\n \u2139\ufe0f Hint: It looks like there is something wrong in your Dockerfile. Try run locally using `qovery run` or build with `docker build --no-cache`\n "}

We collect hundreds of this kind of errors. Based on this data, we try to figure out what are the most common errors that our users encounter.

The Pipeline

The first steps of the process resemble ETL pipeline. First, we Extract data from our data store. Then, we Transform it so that it can be used in our analytical use case. In the end, we come up with a new set of data that is Loaded to a separate location and then used as input in analytics.

The picture below is a visual representation of all the steps of the process. We’ll go through each part more closely in the next sections of the article.

Extract

The first step in our pipeline is exporting the data from our data store. Given the amount of data we have and the fact that the database is used in production by other platform functionalities, we take a daily dump/backup of the data and use it as input in the following pipeline steps.

Transform

The data we store, however, is not structured well for what we want to do. It was not designed for processing error messages in the first place - its primary purpose is different. Thus, we need to preprocess the data before it's useful for our goal.

As an example - to improve the performance of the Qovery platform, we batch deployment events we receive, which results in multiple events being stored in a single unit. So, to prepare the input data, the first step we take is flattening those messages into a single flat list of deployment events.

After we have our input (the flat list of raw error logs), we start another step - the data cleaning. To provide sharp and correct answers, we need to structure our data to be more accessible to process and segment in the algorithms we use further in the pipeline.

Those steps are pretty standard in NLP and include things like:

lowercasing messages
removing punctuation
removing whitespace
removing empty messages

The code for this is very simple - it’s just executing data mapping functions on our input data:

 output = list(map(no_uppercase, data))
 output = list(map(no_numbers, output))
 output = list(map(no_punctuation, output))
 output = list(map(no_stopwords, output))
 output = list(map(no_whitespace, output))
 output = list(map(no_qovery_specifics, output))
 output = list(map(no_unicode, output))
 output = filter(non_empty, output)

And an example of mapping function:

def no_numbers(log): return {
 "scope": log["scope"],
 "state": log["state"],
 "message": re.sub(r'\d+', '', log["message"])
}

The goal is to make the logs structured efficiently for the ML algorithms.

Load

At the end of the Transform step, we end up with a relatively small set of data that, for now, we just store in a JSON file and use as an input for our simple NLP scripts.
Python

Python is excellent in how simple the language is and the number of battle-tested libraries existing in the NLP/ML space. Even though we don't use Python much at Qovery, it was an easy choice to pick it in this case.

We didn't have to implement much ourselves. Each algorithm is already implemented and battle-tested by many of the popular Python libraries, starting from data cleaning, going through later steps as vectorizing data, clustering data, and so on.

All we had to do was prepare the input data, configure the libraries, and play with parameters to achieve the best results - the Python ML ecosystem is vast and provides everything you need, so you don't need to implement much yourself.

The libraries we used:

NTLK
Gensim - Doc2Vec
sklearn

Vectorizing Data

After the data is transformed, what we want to do, is to vectorize our text data (error messages). Why would we want to vectorize the data, and what does it mean?

In NLP, vectorization is used to map words or sentences into vectors of real numbers, which can be then used to find things like word predictions, similarities etc.

We can also use vectorized data for clustering, and this is what we want to achieve - group error logs, so we can see if there are any commonly occurring patterns in deployment problems that we can address to improve the success rate of deployments at Qovery.

The method we used for vectorizing data is Doc2Vec from Gensim - using the library is as simple as executing one function with your input data and adjusting parameters:

def transformToVectors(data):
 return Doc2Vec(data, vector_size=80, window=2, min_count=1, epochs=1000)

‍

Clustering Data

In this step, we take our vectors (numerical representations of our documents - in this case - error logs) and group them based on their similarity.

Density-based Spatial Clustering Of Applications With Noise (DBSCAN)

The method we used to group errors is DBSCAN. The principle behind this method is pretty simple - it groups points that are close to each other based on distance (usually Euclidean distance) and a minimal number of points required to create a cluster. It also marks the points as outliers if they are located in a low-density region.

The implementation, similarly to vectorizing data, is just about invoking the library with your data and adjusting parameters:

def dbscan(vecs):
  return DBSCAN(eps=.2, min_samples=5, metric='cosine').fit_predict(docvecs.index_to_key)

Identifying Errors

The result of DBSCAN provided us with dozens of different error groups. Errors in each group are related to each other. In this (manual) step, I went through all the groups, starting from the biggest ones, and dug into the root cause of the issues in the group.

The results were quite accurate - usually, most of the errors in one group were caused by one or two root causes. It wasn't always easy to find the cause - this part required a bit of digging and understanding.

For errors with unclear cause, we came up with a hypothesis and plan to validate our guesses by implementing potential fixes and measuring the results of new deployments later on again.

Insights

The results and insights we got from analyzing the output of our simple ML pipeline:

~23% of errors were caused during the build process using buildpacks to build users apps
~17% - we couldn't determine what buildpacks builder to use for the build
~16.5% - Kubernetes liveness problems failures - primarily due to users applications ports misconfiguration or crashing apps during the startup phase
~6% - another build pack problem - application errors due to more than one process run and the default buildpacks configuration not being able to start the app
~5% - build errors while building Docker images provided by users
and a couple of sub-2% errors, like failures of deployment due to cloud provider limits, problems with cloning Git repositories, and minor bugs in our API or Qovery Engine

Coming up with those insights and numbers would not be possible without automating the process of analyzing deployments. With the number of deployments we have and different types of applications our users deploy, there is no way to do it "manually".

Embracing the data-driven approach allowed us to make use of the information we already have in our databases to figure out what are the most common errors, prioritize the order of providing solutions to the problems, but also enabled us to identify many less frequently occurring problems, which when added up and fixed, should greatly increase the stability of deployments on the platform.

Summary

It's quite impressive what we could achieve in such a short time with Python and simple NLP. A person who has little knowledge in data science can use existing libraries to process large amounts of data and develop valuable insights that can be used to improve the service.

The following steps for us are to address problems we identified and repeat analyzing the error reporting data to see where we improved and what are the new most frequently occurring issues. Now, it's time to make use of the insights we learned and make the builds bulletproof! :)

How to Automagically Take Notes From Podcasts Without Typing A Word

Patryk Jeziorowski — Thu, 20 May 2021 17:35:25 +0000

Listening to podcasts is a great way to learn. It's a shame that taking notes of the most insightful information we hear forces us to pick up our phones or look for our pens and journals. It's disturbing and sometimes not even possible, especially while driving a car or having our hands occupied in any other way. Luckily, there are services and apps that make this process fully automatic, without requiring us to type a word.

What we can achieve

Imagine going for a walk with AirPods in your ears. You hear something very insightful. You press a button on a headphone. The valuable sentence you just heard is saved as text in your note-taking system (alongside the link to the podcast episode with the exact timing of the quote).

Sounds cool, doesn't it? It's pretty easy to achieve by integrating a few services and an app on our phone.

First step - Airr

Airr is a podcast player that allows taking so-called AirrQuotes. AirrQuotes are highlights of the best moments we hear in podcasts. When we hear something insightful, all we need to do is to press a button on AirPods (applies to Apple AirPods users - for other hardware users, you'll probably have other options).

Airr allows exporting all the AirQuotes automagically to other services, alongside text transcription of the quote. It all happens automatically, without requiring us to trigger export manually.

Second step - Readwise

Readwise is an extremely useful service. It's a hub for highlights and notes from other systems - note something in Kindle, take AirrQuote in Podcast app, highlight something in RSS reader - all of this can be automatically ingested by Readwise and stored in one place. Steps for integrating it with Airr are extremely simple.

Right now, I'm exporting highlights from 8 apps and services to my Readwise hub.

But, what is the most important, Readwise also allows exporting everything we ingest automatically to other systems (e.g. note-taking apps) like Notion, Evernote, Roam etc.

Third step - note-taking app

I use Readwise to export all my notes (including AirrQuotes from podcasts, which are stored safely in my Readwise) to the best note-taking (it's an understatement) app in this world - Roam (I'm not sorry for this biased, strong opinion. Roam rulez).

All we need to do to set up the integration is to sign up and follow easy steps from the manual, which takes less than a minute. This process will depend on what app you use to store your notes. In my case, it looked like this.

Enjoy

That's it. Having it all done, we can reward ourselves by going for a walk, listening to a podcast, and taking notes of the best insights with a single button click on our earphone.

Bloomly, a new full-stack project to manage your content online

Patryk Jeziorowski — Sat, 15 May 2021 21:10:12 +0000

In the previous post, I announced that I start my 365 days of blogging challenge. I also released a mini CLI tool that publishes articles to all the major developer blogging platforms (dev.to, hashnode, medium) with one command.

The tool lacks some features, though, and I saw that people have the same problem as I have - they need a centralized place to manage their articles or avoid publishing their content manually on multiple sites. Automating stuff saves time...

This is why I decided to help them (and myself) by creating a service that allows you to write your articles, publish them, and manage them on all the previously mentioned platforms in one place.

Pain to solve

In general, I want to create a tool that will reduce the friction and effort you need to put in to create and distribute your content as a developer. In the future, it should also help you reach more people and let you analyze what works best and what your audience like to read about.

Features

The MVP will cover writing articles and integrations with all the platforms (publishing, updating, and deleting articles). It also covers all the basics like signups, creating projects and adding collaborators.

Next steps I have in my mind if the project gains traction or if I find it helpful to my blogging journey:

displaying article statistics from all platforms in one place
generating article covers, adjusting stuff best for the given platform (e.g. cover sizes), in general - reducing the effort of publishing
marketing - integrations with Twitter, LinkedIn, Instagram, Facebook, to help you announce to the world that your articles are published

Tech stack

To quickly build the backend and GraphQL API, I decided to go with Hasura. It's not the only backend component - to perform custom business logic, I need a separate microservice or serverless functions that Hasura will call on certain events. For this, I decided to go with Golang and a great Echo HTTP framework. I'm still thinking, though, if I should use Node.js, as Hasura provides some excellent tooling that helps you generate code for your serverless functions.

For the frontend - React.js with Next and Tailwind. I've been a fan of those technologies since their humble beginnings, so the choice here was pretty easy for me.

For deploying and hosting the app I'll use Qovery - it's a startup that aims to provide great developer experience in deploying and building full-stack applications in the cloud. For disclosure - I'm building this platform during my working hours :P.

Progress

I've just started today coding the backend part - most of the MVP API and data modelling is done.

I still need to implement the custom actions (interactions with APIs of the publishing platforms) in the Golang microservice. When it's done, I'll jump into coding the frontend part.

Collaborators are welcome

I can do everything by myself, but it would be much more pleasant to work in a group, so if you are interested in building this kind of project, or you feel the pain that it aims to solve, feel free to reach out to me - we can build it together. Backend, frontend, UI/UX designers - everyone's help would come in handy! Just leave a comment or find me @ Twitter :).

Leave your feedback and feature ideas

If you have any feedback or an idea that I could integrate into this project, feel free to leave a comment or reach out to me @ Twitter!

3 Steps Protocol to boost your Learning Speed and Memory

Patryk Jeziorowski — Thu, 13 May 2021 18:51:20 +0000

In this post, I'll show you how you can use hormones that are naturally produced in your body (cortisol and epinephrine, a.k.a adrenaline) to help you learn faster, improve your memory and increase your overall performance.

If you don't have the time to read the whole article, I'll give you the three steps protocol to follow to get all the benefits. I strongly recommend reading the entire article to understand better the science behind which will allow you to implement it in your life more easily and adjust to your needs if needed.

3 Steps Formula to improve your learning and performance

Start the session with 90 minutes of deep focus learning or work (expect distractions in the first ~10 minutes, as well as at the end of the session)
Increase adrenaline in your body using the Wim Hof breathing or any other breathing method
Go into a non-sleep deep rest state (e.g. meditation, or something equally relaxing) for about 10-20 minutes.

Additionally, make sure at the end of the day, your sleep is high quality.

The magic (science) behind

Many of you may know those hormones (cortisol and adrenaline/epinephrine) as something terrible, released when you are stressed, in a fight-or-flight mode. It's true, partially. I would like you to think about those hormones as hormones of alertness, activation, energy, though.

In fact, cortisol and epinephrine are vital to your health. They are helping you boost your immune system, be alert and ready to act, boost energy levels, and have many other positive effects, including better learning performance.
Cortisol is vital. You shouldn't call it a stress hormone. It makes you more alert and ready to take action, which is often perceived as anxiety if it raises too high levels.

Cortisol can be more thought of as a hormone of energy. It makes you want to act, increases your heartbeat, makes you alert and turns off some non-vital processes like digestion.

In general, cortisol can be a good tool if released at the right time, for the right amount of time, and in the correct dose - the same goes for adrenaline.

Research says a sharp increase in cortisol and adrenaline leads to better learning and performance. Epinephrine is actually your best friend when it comes down to learning and remembering.

It does so because it's usually released before extreme situations, e.g. you'll easily remember every detail of what happened before a car accident, and you'll remember it for a long time. I still remember how I crashed my uncle's car... It's all about how much, when and for how long you release cortisol and epinephrine.

This is why increasing your adrenaline levels after a learning session may help you learn faster, and remember more. This is something deeply ingrained in human evolution. The same way a child learns not to touch a hot stove, you learn whatever you want to learn, as long as you get the adrenaline boost right after you stopped learning.

When those hormones are harmful?

They are harmful when being in a stress state is chronic and not controlled. You can not stay in this highly alert state for long. If you are stressed for more than a day you can consider it harmful.

Also, remember that you want those shots of hormones right AFTER the learning session, not while learning!

How to control it when it's chronic?

Many methods may help you reduce cortisol levels in your body, but it's a topic for another article. Among those, you may find things like... meditation, breathing, deep rest, and all of the well-known relaxation methods.

Avoid fasting, high-intensity training, cold showers as they all tend to increase cortisol and adrenaline levels in your body. Try to sleep well. Take care of yourself first. The basics are the most important!

However, if you do everything well, take care of all the basics but still struggle, you can look at supplements like Ashwagandha.

I'll cover the topic of dealing with chronic high levels of cortisol in your body in one of the next articles.

Last words

To summarize - the so-called stress hormone and adrenaline are not your enemies. They are vital for your well being and immune system. Use them as tools, take the control and get benefits in your learning and performance.

First week of the 365 Days Of Blogging Challenge!

Patryk Jeziorowski — Tue, 11 May 2021 19:53:30 +0000

So, in the previous post I announced the challenge of blogging daily for the next 365 days or sending $1000 to a random person chosen from the comments section.

After doing it I received tons of comments (hopefully not just because of the potential easy $ you may win if I fail :D) about what am I going to write about, about the quantity and quality of the articles and so on.

A few fellow dev.to members suggested that I should substitute the goal of "1 article daily" by "x words daily" to make sure the published articles are high quality.

Quality over quantity

I agree that goal of writing "X amount of words daily" may lead to higher quality posts, so I decided to follow the suggestions I got in the comments section, and instead of publishing 1 article a day, I'll be writing 500 words daily, or 3500 words weekly.

This is a quite aggressive goal - as @InHuoOfficial mentioned in his comment, this would result in writing basically two novels in one year (over 180K words!).

Topics of the posts

To answer all the questions I had about topics of the articles - I'll be writing about things I'm currently working on at startup I help to build, about things I'm currently learning, about things I'm interested in.

I'm a pretty geeky tech person, so it's going to all revolve around software, programming and tech topics. You may also expect stuff about productivity, biohacking, and basically anything that may help you in your tech journey.

If this challenge goes well, I'll also describe my case study and show you how I managed to write and publish consistently over such a long time.

Writing in Public & Transparency

To keep the challenge fair and give you visibility into the process, besides publishing articles, I'll be publishing drafts of posts to a public Github repository (which is the repo of my private blog BTW).

You'll be able to track what I'm working on, topics of following articles, number of words or whatever you want to know about my writing.

Changes in the challenge

So, as I previously mentioned, I'm changing the numbers in the challenge - instead of publishing 1 article a day, I'll write 500 words a day, 3500 words a week, over 180k words (2 novels!) a year. I'll do the counting, reporting and tracking if I meet the challenge's goals every week during the weekend.

If you want to be informed about progress and the results (and also about the potential $1000 winner in case I fail), you can sign up to the newsletter I quickly created for the purpose of this challenge.

Stay up to date

Besides the newsletter, I'll publish all the articles (and challenge updates) here:

And drafts:

https://github.com/pjeziorowski/cyberwritings/tree/main/content/drafts

It all starts this week!

Please let me know what do you think about the changes and the form of the challenge. I'll try to constantly improve the process, but I'd also like to start the challenge ASAP (this week), so any feedback now is highly appreciated!

365 Days of Blogging Challenge

Patryk Jeziorowski — Mon, 10 May 2021 17:02:55 +0000

Everyone sometimes struggles with consistency. Do you want to develop a good habit but often fail after a few days? Well, you are not alone.

To help myself with that (and possibly you), I come up with the idea of making a public commitment and finding accountability partners.

Public commitment

This post is my public commitment to writing and publishing articles daily for the next 365 days. It's well over any magic number you hear that is necessary to form a habit. For my liking, it's fair enough.

Accountability partners

To hold myself accountable (and to make you more interested in helping me stay consistent), I declare that I'll pay $1000 to one of my accountability partners (by whom I mean anyone who comments on this post on dev.to) if I miss a day in publishing articles in the next year.

The rules

One article a day published, no excuses.
No article published - a script chooses a random person from the comments section to transfer money to their bank account.
The way of choosing a random person may change with time - I want to make it automated and public, to provide transparency and fairness (and to prove I'm taking it seriously!). Feel free to propose your ideas on how to approach this problem.

Join me in the challenge

I encourage all of you who want to develop a good habit of putting yourself out there to join the challenge.

Of course, your numbers may be different. Maybe your goal is to publish just one article a week. Maybe $1000 is too much or too little to make you feel uncomfortable.

Choose your perfect numbers and join me in the challenge! If you struggle with this, DM me on Twitter, and I'll do my best to help you come up with numbers that will work for you.

And please, let me know what you think about this idea. Feedback highly appreciated!

How I publish articles to all developer platforms (and my private blog) in one shot

Patryk Jeziorowski — Sun, 11 Apr 2021 07:47:06 +0000

Where to host your blog?

Qovery CEO, Romaric has just started his own blog on hashnode. I become jealous, so I started thinking about blogging again. I couldn't decide where to publish my content, though:

The answer > everywhere!

To reach the highest number of people, I decided to publish it everywhere with automated content distribution tools. Unluckily, I couldn't find any tool that would meet my needs:

allowing me to write just once
have it published automagically everywhere

In this post, I'll show you how I achieved what I wanted - I hope you'll find it helpful on your own blogging adventure.

Markdown

My blog uses markdown to build the HTML for the articles. Markdown is quite good for it as it's very portable. All, Hashnode, Dev.to, and Medium support markdown in their APIs. This is perfect - it allows me to write a single markdown file and have it published everywhere.

After the markdown file (the article) is written down, we need to use APIs. So, the tool needs to take the markdown and deliver it in the correct format to APIs of all the different platforms we target.

CLI

The first version of the tool is a simple CLI app. It's relatively fast to create and validates the concept quickly - we don't need backends, UIs or any other crazy stuff from the very beginning. BTW, I named the app Rollout to refer to it in this post more easily, hah!

Using Rollout

I won't go over the details of how the CLI is implemented (as it's not the topic of this post, it's very simple, though - you can see the code here).
I'll jump straight into showing how to use the tool and how simple it is to have your posts published everywhere.

1 Install the tool

MacOS

brew tap pjeziorowski/rollout-cli
brew install rollout-cli

Windows/Linux

If you are on Linux/Windows, for now you need to build the app from the source. I'll improve it soon!

2 Write the article - this is definitely the most challenging part! Luckily for you, I wrote one that you can use for the test!

echo "---
title: "Test Rollout CLI"
canonical_url: https://google.com/test
tags: [Blogging, Automation]
---  
## Hello Rollout!
" > ./test.md

3 Distribute the article

rollout test.md

P.S. you also need to provide API tokens for the tool to use, it'll show you a hint you when you give it a try.

Congrats! Your post is now published everywhere

Hey... Did you forget somethin? You only published to Dev.to, Hashnode and Medium. What about your (and mine!) private blog?

Well, in my workflow, I publish posts to my blog by simply pushing markdown to my Github repository, so the tool doesn't have to do anything more. It's enough for me now, but in the future, Rollout could also be integrated with any headless CMS, for example. If I had a WordPress blog, I would simply use the WordPress API to push the article there. Luckily for me, all I have to do is store my posts on Github. If it's the same for you, welcome to the happy bloggers club!

It's open-sourced!

As I mentioned earlier, you can see the tool's code in its Github repository.
If you like the idea or the tool works for you - please give it a star and leave a feedback comment (if they are yet implemented on this site, ha) or contact me on Twitter/Linkedin directly.

If I see interest in the tool, I'll put more work to make it more versatile and probably create a UI (SPA) and some backend for managing the content and configuration. Contributions and suggestions are also very welcome!

BTW - this article was published with Rollout!

A month after switching from Slack to Discord in a remote-first tech startup

Patryk Jeziorowski — Thu, 14 May 2020 18:02:36 +0000

Nowadays, Slack is often the default choice for an online communication tool in the tech industry. Startups, enterprises, open-source projects - they all use Slack to communicate within their organization but sometimes also with their users and community. Our startup was no different. In this article, I explain what made us look for Slack alternative and what are our impressions after a month of switching to Discord, so you can learn from those before you make your decision.

The background

Qovery is a remote-first startup founded at the end of the last year. I was hired as the first full-time employee. We are all distributed and work remotely. All our communication happens online. Meetings, plannings, brainstorming sessions, talks with founders, technical discussions, and all the rest - it all happens online without exception.

Our product is focused on solving the developers' problems. We help them in deploying their applications on the cloud. We work with all types of programmers - passionate hobbyists, innovative startup guys, serious enterprise architects but also programming newbies. This is why we work with many different kinds of applications and need to be there to answer various community questions.

This all makes it crucial for us to have a tool that allows communicating flawlessly with our community but also internally within our startup, as all our communication happens online.

What made us switch

Slack is not a bad tool. In fact, there's a reason why it's so popular. But, like all tools, it's not perfect.

What we didn't like was primarily the message history limit. On Slack, you have to pay per user. If you want to preserve the chat history for a growing number of community users, this can get pretty expensive quickly. In this regard, it doesn't really support our needs. Don't get me wrong - we are willing to pay for the tools we use, but Slack pricing model is not well suited for a community communication tool.

We talk (voice) a lot. We think it's important to communicate effectively using our tools, especially when that's the only channel of our verbal communication. Slack was not doing its job well in this regard. Sound, connection issues, and noticeable delay of sound despite decent internet connection made the experience at least not perfect. It's not only Slack issue - we tried many other tools, too, and they all often face similar problems.

Solution?

Discord? It's a tool for online gamers, isn't it? Maybe, but... "On paper" it looked like it could fix all the problems we had with Slack. No history limit, focus on great voice communication... We decided to ignore the "it's a tool for gamers only' stereotype and took a bold move to give it a try in our organization. What's the result?

What was expected to be better is in fact better

In practice, all promises Discord gave us, in real day-to-day usage, turned out to be true:

Pricing model - we no longer have to pay per user to keep our chat history. You could use it, in fact, for free. We pay less than 80$ per month now for even better audio quality and HD video calls. The price won't change with our growing number of community users.
Voice / Video chats. This is where Discord shines. The audio quality is excellent, screen sharing works flawlessly, the latency between you speaking and your listeners hearing it is much lower than on Slack and other solutions. Also, what I really like is you do not have to call somebody directly or prepare a group calls - you can just enter a voice channel (Teamspeak and Ventrilo nostalgic memories...).

What was expected to be worse, is in fact worse

Integrations - we were aware that as a mainly gamers' tool, Discord lacks some of the integrations we used on Slack. Slack has a huge advantage in this space. However, thanks to webhooks combined with Zapier, we were able to configure all integrations we had before also Discord.
Threaded messages - we were aware of the fact it's missing in Discord, and in fact, it's painful. I do miss it. I wish it was there.

What surprised positively

What surprised me from the first second I launched Discord app was the smoothness and responsiveness of the app. It runs truly, noticeably, SMOOTHER and FASTER than Slack. Using Slack in comparison to Discord feels like being in a slow mode for me now. I completely didn't expect this (in fact I was not aware that Slack was so clunky). It's simply a pleasure to use Discord.

Another thing that surprised me is that Discord seems to grow really fast. In just a month of our usage, the added noise suppression, which eliminates random noises from your background and an option to turn on the webcam during talks on group channels.

What surprised negatively

What surprised me negatively the most is a very inconvenient upload of very long texts (e.g. application logs). If your copy-paste a very long text, it won't be displayed in the chat in any way - it appears as a text file to download instead.

Another thing - file upload size limits are a bit restrictive. There are no limits for the workspace like on Slack, but for a single file upload, the limits are pretty harsh (8MB / 50MB/ 100MB depending on your plan). This means you'll have to share your files elsewhere.

My final thoughts after one month of switching to Discord

I'm selfish. I wish Discord would switch focus from gamers to professionals. It would be then the perfect tool for any IT organization. But for now, these are just my dreams - the reality is that Discord is much better for voice conversations. The app works much smoother and feels more responsive & modern. Chat is worse due to the lack of threaded messages.

In my opinion, you should use Discord if:

you value quality voice conversations
you communicate a lot with your users/community
you don't mind using gamers focused tool (the UI is less suited for enterprise usage than Slack)

I think Discord may gradually turn into a more business-oriented tool. They add features that are useful for IT teams. There's yet a bit to be done, but I hope it will naturally go in this direction. There are a lot of open-source communities using Discord to build their communities at the moment (including Rust, Django, Hasura, Typescript, and many others) and I believe Discord's popularity will grow in our industry.

And, it the end, they use Rust so no wonder why Discord works so smooth! :)

P.S. If you want to try Discord or ask me or our team any question, feel free to join our Discord server.

Productive and simple way to deploy Dockerized applications

Patryk Jeziorowski — Wed, 06 May 2020 18:51:22 +0000

In recent years, Docker has been becoming more and more popular tool used to deploy web applications. According to Datadog in 2018, the adoption of Docker in large organizations reached about 47 percent and almost 20 percent in small organizations. This report it two years old - no doubt Docker is even more common now.

In my opinion, knowing Docker basics is an essential tool in the toolbox of every software engineer, especially in the web development ecosystem. In this article, I'll demonstrate the easiest way to Dockerize and deploy a simple application. Before we dive deep into practical steps, let's first answer two essential questions - "What is Docker" and "Why should I use it" in the first place.

Docker in a nutshell

Docker is a tool that makes it easy to build and deploy your applications, typically to the cloud environment. It allows you to package your application in a container that contains your app with all of the things it needs, such as libraries and other dependencies. Then, this package can be run on any machine with a Docker engine installed, no matter the underlying configuration or system distribution.

Why should I use Docker?

It works on my machine sentence has become a meme in the software world. You can even get a sticker on your laptop:

Making applications run consistently in various environments is one of the issues addressed very well by Docker.

Docker makes sure that your containerized applications run in the same way on your machine, on your friend's machine, and on the AWS server (and anywhere else where Docker engine is installed). It is truly a superpower. As a developer, you no longer need to worry about the underlying system. After you Dockerize your app, you can be sure that it behaves in the same manner in your development, testing, and production environments, as well as on your local machine. It makes building and testing applications way more comfortable than it was before.

Another reason why you should be interested in Docker is the popularization of cloud, microservices, and Kubernetes. Docker is the first-class citizen in the cloud-native world, so if you want to take the full advantage of scalable, cloud-native application architectures, Docker is the way to go.

How to deploy Docker containers

Let's move on to the practical application and usage of Docker. We'll now build a very simple web application that responds to HTTP requests, dockerize it and deploy to Qovery - a scalable Container as a Service platform.

Create a simple application

For the sake of simplicity, we'll create a simple Node.js application that returns a Hello, World text in response to HTTP requests. I choose Node.js here because it's simple and popular technology, but you can use Docker with basically any language and framework.

Let's create an empty folder for our new application and initialize an empty Git repository:

mkdir deploying-docker
cd deploying-docker
git init

Now, create app.js file with the source code of our server:

const http = require('http');

const hostname = '0.0.0.0';
const port = 3000;

const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello World');
});

server.listen(port, hostname, () => {
    console.log(`Server running at http://${hostname}:${port}/`);
});

It is a very simple server that returns "Hello World" text on its root endpoint. After it's done, we want to make this app run in a Docker container. To do so, we need to create a Dockerfile.

What is Dockerfile?

Besides containers, Docker uses the concept of Images. Image is a template used to create and run containers. Dockerfile describes the steps required to build the image. Later on, this image is used as a template to run containers with your application.

You can think about images and containers as a good analogy to classes and objects (instances of a given class) in the Object-Oriented Programming world.

Create a Dockerfile that will allow us to run our Node.js app in a container. Create a file named Dockerfile with the following content:

FROM node:13-alpine

RUN mkdir -p /usr/src/app

WORKDIR /usr/src/app

COPY . .

EXPOSE 3000

CMD node app.js

Let's discuss all lines of the Dockerfile:

FROM node:13-alpine specifies the base of our Docker image. It's a base used to get started with building an image.
RUN mkdir -p /usr/src/app creates a new empty folder in /usr/src/app
WORKDIR /usr/src/app defines the working directory of our container
COPY . . adds the contents of our application to the container
EXPOSE 3000 informs Docker that the container listens on the specified network port at runtime
and, finally: CMD node app.js is the command that starts our application.

Now we got all basic things we need to run our application in a Docker container! Let's try it out:

Build Docker image of the app using docker build testing/docker .
Run a container with our application by executing docker run -p 3000:3000 testing/docker

the -p 3000:3000 flag makes container port 3000 accessible on your localhost:3000.

Great! The container is up. Run docker ps to see the list of running containers and confirm that it is indeed running.

Now open a browser at http://localhost:3000 to see that the application in a container responded with Hello, World message.

Did it work? Great. Our app works well in the Docker container. It's adorable, but we want to share our app with the world - running applications only on our own machine won't make us millionaires!

Container as a Service

To deploy our Dockerized application, we'll use Qovery. It's a Container as a Service platform that allows us to deploy Dockerized apps without any efforts. Qovery is free up to three applications (and databases!) in the community version.

Install Qovery CLI

To Sign Up and install the CLI, you can follow the steps described in this link.

After you have access to Qovery, it's time to deploy the application.

Deploy the docker container

Run qovery init
Choose application name, e.g., node-app
Choose project name, e.g., testing-docker
Commit and push your changes to Github: git add . ; git commit -m "Initial commit" ; git push -u origin master" (create an empty repository beforefor your application on Github before if it's not done yet)

Voila! That's all. Your Dockerized application is being deployed as a Docker container. To deploy a Docker container on Qovery, all you need is a Dockerfile that describes containers with your application + running qovery init command to initialize Qovery. From now on, Qovery will build and deploy your Dockerized application after you make any changes in your repository to scalable Kubernetes clusters as a Docker container.

To check that your application is in fact deploying, run qovery status:

BRANCH NAME       | STATUS  | ENDPOINTS                            | APPLICATIONS    | DATABASES
master            | running | https://some.url.qovery.io           | node-app  | 

APPLICATION NAME  | STATUS  | DATABASES
node-app          | running | 

DATABASE NAME     | STATUS  | TYPE       | VERSION | ENDPOINT | PORT     | USERNAME | PASSWORD | APPLICATIONS

Summary

In this guide, you learned the essential basics of Docker. You also learned why you should be interested in using it, and how to deploy your application to the cloud as a Docker container. This is all you need to know to improve your development experience and deploy your application to the cloud with ease! If you have any questions or feedback please do let me know in the comments or join Qovery Discord server and feel free to speak your mind.

Do you use a monorepo?

Patryk Jeziorowski — Thu, 09 Apr 2020 13:33:01 +0000

I'm curious how many of you (and how, if so) use a monorepo. Do you use it for both backend and frontend? Do you use any tools to help you with that?

I would be grateful for your answers.

How to build and deploy realtime GraphQL APIs in a few minutes

Patryk Jeziorowski — Thu, 09 Apr 2020 09:18:50 +0000

Before we dive deep into details, I'll quickly describe the tools I used to build and deploy a realtime GraphQL API and tell you why you should fall in love with GraphQL and all the tools I used.

First, why to use GraphQL?

GraphQL is a query language for APIs and a runtime for fulfilling those queries with existing data. GraphQL provides a schema that describes the API and allows clients (e.g. your frontend or mobile application) to easily fetch data they want and nothing more.

Here is what you get from using GraphQL instead of standard RESTful APIs:

GraphQL queries get exactly what you need, nothing more and nothing less
Instead of making multiple requests to fetch required data, you make just one request to one endpoint
GraphQL schema is typed, what makes the contract between frontend and backend clear and understandable

If you are a frontend engineer, you will not like to consume other APIs than GraphQL after trying it out. It makes your life so much more pleasurable and easy.

You don't need to know GraphQL to follow this article. All you need to know is that GraphQL allows you to define contract between frontend and backend and do operations on the data you are interested in.

Productivity boosting tools

Hasura is an open source engine that connects to your databases & microservices and auto-generates a production-ready GraphQL backend. By using Hasura in conjunction with Qovery (platform that combines the power of Kubernetes, the reliability of AWS and the simplicity of Heroku to allow developers deploy their apps with pleasure), you get a blazing fast, auto-scallable and extensible solution to quickly build your applications.

Why Hasura?

Consuming GraphQL APIs is a pleasure. We'd like to have more GraphQL APIs. But those APIs do not come out of nowhere. Somebody has to implement them first - the data won't just flow out of the database through the schema to your frontend automagically, right? Well... with Hasura it will!

Hasura allows you to bootstrap a realtime GraphQL API in seconds by simply modeling your data. Hasura will do the hard work of translating your needs into queries to the database and translating them to GraphQL schema. Thanks to this, all you need to do is to define the data you want to store in the database - Hasura will do the rest.

This is unbelievable how much time it saves. If you don't believe, try implementing a GraphQL server yourself - with all the featuers and options that Hasura offers.

If you have doubts about flexibility - you don't have to worry. If you need to perform a very custom business logic, you can implement this part in any language you want and connect it to Hasura engine. This way you will not only save a lot of time, but also have flexibility to write your custom code if needed.

Why Qovery?

Managing infrastructure is hard and takes time. Developers want to focus on building their apps instead of wasting time on managing servers or databases. Qovery is tool that does it all for you - all you have to do is to write your application code. It's *powered by Docker and Kubernetes * underneath, so you get all the benefits of using those modern tools without the complexity and costs of learning and managing them.

Qovery is also a great fit for Hasura - its free plan allows you to deploy Hasura and database for free, without any limits, performance degradations or putting your app to sleep like it's done on other platforms.

If you have any questions regarding this post or other things, feel free to reach me on Discord.

Hasura deployment on Qovery

Deploying Hasura on Qovery is really easy. All you have to do is to bootstrap a project using Qovery CLI in a Git repository & export environment variables required by Hasura.

1/ Bootstrap a project with Qovery CLI (the script will ask you for project and application name, which you can choose as you like)

qovery template hasura

2/ Point Hasura to your Postgres database and enable Hasura Console using environment variables

qovery application env add HASURA_GRAPHQL_DATABASE_URL '$QOVERY_DATABASE_MY_POSTGRESQL_DATABASE_CONNECTION_URI'
qovery application env add HASURA_GRAPHQL_ENABLE_CONSOLE true

3/ Commit and push your changes

git add .
git commit -m "Deploy Hasura on Qovery"
git push -u origin master

Well done! After pushing changes, Postgres and Hasura deployment will start. You can use ‍qovery status --watch to track the progress. Once the deployment is done, you’ll see your Hasura application URL in the status:

Creating realtime GraphQL APIs

Navigate to your Hasura application URL and choose Data tab in the console:

In this section we'll configure our data model. Now, click on the Create Table button.

You’ll see the table creator. We are going to create a simple "Todo" items table. We'll name it "todos" and the table will contain three columns:

1. id - unique identifier of given "Todo" item
2. title
3. description - optional description of "Todo" item

Fill the form as in the screenshots below to prepare the table.

At the end, we should specify our id column as a Primary Key.‍

The table is ready to be created. Click Add Table button at the bottom of the page.

Voila! The table has been created in Postgres and Hasura has exposed GraphQL APIs to interact with our data.

Testing GraphQL APIs

To test the GraphQL API, navigate to the GraphiQL tab and run the following query:

mutation query {
  todos {
    id
    title
    description
  }
}

As you can see, Hasura returned an empty array of "Todo" items. Let’s add a "Todo" item by executing the following query:

mutation {
  insert_todos(objects:[
    {
      title: "My first TODO"
      description: "It's very important TODO item"
    }
  ]) {
    affected_rows
  }
}

After you run the above query, in the response you'll see information about one affected row. Congrats! You have created a first "Todo" item. Let's now move further to a more interesting topic.

GraphQL realtime APIs

It's time to use a realtime GraphQL APIs - GraphQL Subscriptions. Subscription allows you to fetch data and get updates about any changes that occur in data you are interested in.

In the GraphiQL, run the following query:

subscription {
  todos {
    id
    title
    description
  }
}

In the response in the right-hand of console you'll see a "Todo" item you have created previously. That's great. Let's now test if the subscription really works - open one more Hasura console in a separate browser tab and navigate to GraphiQL.

Execute the following query a few times:

mutation {
  insert_todos(objects:[
    {
      title: "Another TODO to test subscriptions"
      description: "Subscriptions!"
    }
  ]) {
    affected_rows
  }
}

At the same time, keep an eye at the subscription. Each and every newly created "Todo" item automagically appears in the subscription response!

Conclusions

By following this article you quickly deployed a realtime GraphQL backend using Qovery, Hasura and Postgres database.

Using this stack saves you tons of time. Deploying it on Qovery is extremely easy. We take care of your application and your database. With Qovery and Hasura all you have to do to expose quality, realtime GraphQL backend is just a few clicks. After minutes your application is ready - define your data schema and expose GraphQL API to the world!