DEV Community: Karl Eriksson

Scraping HackerNews with GPT-4

Karl Eriksson — Fri, 03 Nov 2023 10:34:46 +0000

I wanted to share a project I recently created - An automated scraper for that can scrape any website and store the text content as JSON using GPT. I thought this might be helpful for anyone interested in scraping data or working with APIs.

Step 1: Tech Stack

After exploring various ways to achieve this, I opted for a no-code solution. In the end I chose the no-code platform Clevis to cobble together the required steps and automate the process by running it on a daily schedule.

Step 2: Scraping the content

By using an HTTP Request step in Clevis, I can make a GET request to any website and scrape the text content.

Step 3: Using ChatGPT to parse the content as JSON

Next, I use the scraped text from HackerNews and prompt ChatGPT to create a JSON object with a schema that I provide in the prompt. In this screenshot, the scraped text is referenced as steps.scrape.output.

Step 4: Storing the result

Now that ChatGPT has provided me the result, I can store it in my own database with another HTTP Request step that calls an API I built.

Step 5: Scheduling

By enabling a schedule in Clevis, I can have this run daily to store the top HackerNews posts for later curation.

Personalized Newsletters Using AI

Karl Eriksson — Thu, 26 Oct 2023 15:50:33 +0000

I recently explored how to build my own personalized newsletter to avoid having to sift through multiple news websites every day. The app that I created fetches the latest news about a subject of my choosing from a news API, summarizes and filters the data with the help of ChatGPT, and sends it to my email. In this post, I'll walk you through how I accomplished this project.

Step 1: Tech Stack

After exploring various ways to achieve this, I opted for a no-code solution. In the end I chose the no-code platform Clevis to cobble together the required steps and automate the daily email sendout.

Step 2: Data Gathering

I started by finding a suitable news API. There are several options available, but I settled on one that provides up-to-date information about startups - NewsAPI.org. The API offered a range of endpoints and parameters to customize my data retrieval. In Clevis, I was able to call this API to fetch data about any subject for the current day.

Step 3: ChatGPT Integration

In Clevis I used the result from the NewsAPI.org API call and prompted it to summarize the news in the form of an HTML formatted newsletter.

Here is the prompt I used which works surprisingly well given the simplicity.

Step 4: Sending the email

Clevis comes with built in functionality for sending emails so I simply configured it to send the HTML formatted email that ChatGPT produced for me. Here is an example of how the email looked. ChatGPT even included images from the API response. I believe the formatting could be improved further either by tweaking the prompt or by using my own email template.

And here is how the finished app looks in the Clevis editor

Going forward

I belive I will continue to iterate on this project to use data from multiple news sources and websites. One challenge is the token limit of ChatGPT which I might have to find a way to get around.

CI/CD for SaaS Products

Karl Eriksson — Sun, 16 Oct 2022 13:39:31 +0000

Volca is a SaaS template that comes with a smooth CI/CD setup powered by GitHub Actions out of the box. Ship features faster for your SaaS using an automated deployment strategy.

Learn how we designed our CI/CD setup with the goal of shipping changes in a fast, reliable and developer friendly way.

Branching strategy

The first step to design a CI/CD setup for your SaaS is to define a branching strategy. There are many ways of working with branches to make sure you work in a reliable and developer friendly way. Building Volca, we have focused on simplicity and developer experience while maintaining a reliable deployment flow. That is why we have went for a trunk based strategy where a single branch, the main branch, is the one that all developers branch off from.

Environments

To be able to test your code before it is usable by your customers, you need isolated environments in which different versions of your code is running.

In complex enterprise setups, there might be a large number of environments. When building a SaaS from scratch however, you need to keep things simple to be able to ship new features fast. That is why Volca comes with two environments with automated deployments out of the box: staging and production. In addition, developers have their own local environments where code is tested during development.

Local

When running a Volca backed application in your machine, you make constant changes to the code which are instantly reflected in the local environment. Once a developer decides their changes are ready to ship, they are pushed to a feature branch and a pull request is created to the main branch. When the pull request has been created, other developers (or just you if you are a solo founder) can review the changes and finally merge them to the main branch.

Staging

Once the changes have been merged to the main branch, the updated code will be deployed to the staging environment. Here, you can test your code running in a similar environment to production and make sure nothing breaks. It is recommended to test all important features and make sure they work as expected before moving to production.

Production

The production environment is the one that your customers use and it is critical that it is fully functional at all times. This environment is deployed by manually triggering a deploy in the GitHub interface. This is to make sure you do not ship code that has not yet been tested in the staging environment.

Workflow

As a developer, more branches to switch between equal a higher risk of something going wrong and wasting time. That is why we chose to use a single branch for all development: the main branch.

When building a feature, all developers branch off from the master branch and run the application locally.
Once the feature is ready to merge, the developer creates a PR towards the main branch
When the PR has been merged, a GitHub Action is triggered that deploys to the staging environment
Once the feature has been tested in staging, a deployment to production can be triggered manually
Once a production deployment is triggered, a tag is created for the commit that was deployed into production

How We Used Mock APIs to Supercharge Our Microservice Testing

Karl Eriksson — Fri, 04 Sep 2020 22:09:35 +0000

Note: This is a case study from an earlier project that we developed for a client. Some details have been left out or modified for confidentiality.

Introduction

After a long time developing and managing a huge monolithic application we decided to travel down the inevitable route of breaking it down into small independent microservices. This came with quite a few challenges where many of them related to testing. We no longer managed only one large application but many small ones which we should deploy and test individually.

In this article we will describe our microservice journey and what we did to accelerate our testing strategy by leveraging mock APIs.

Our Architecture 🗺️

Monolithic arcitecture with a single application using loads of different AWS services such as Lambda, API Gateway, DynamoDB, Kinesis, ElasticSearch and Cognito all deployed through CloudFormation.

The legacy architecture that we were moving away from was in fact not really ancient. We were deploying everything in AWS using infrastructure as code (AWS CloudFormation), we were running serverless functions (AWS Lambda) instead of managing VMs or container clusters and from the outside things looked pretty good. However, when you dug into the code and saw all of the entities and different services within you quickly understood that we had created a huge monolith with code dependencies that looked like a spider web across the different parts of the application.

The main challenges with this architecture was:

Time consuming deployments: A release took a lot of time and required careful monitoring as to make sure nothing broke. We needed to sync everything up and deploy during a specific time to make sure we had time to correct things. Many precious developer hours went into monitoring and fixing release issues.
Developer experience: Since the code base had grown so large it was very hard to modify the existing code without knowing about the different dependecies between other parts of the application. Running the application locally was a strict no-go. Deploying to test your code when deployed to the cloud could take up to 20 minutes because of the ever increasing number of resources that we had to deploy.
Testing: For a developed feature to be merged into a release branch all tests for the entire monolith had to pass. These tests were time consuming and could take up to 30 minutes to complete. Waiting for the tests to pass when you made a small change lowered development and review speed. This is what we will focus on for the rest of the article.

Microservices were an obvious choice for us since we could...

Have small, fast and independent deployments of each microservice
Split the monolith into smaller graspable code repositories with a clear purpose that developers could understand quicker
Test each service individually with small test suites that finish quicker. No need to run the entire suite before releasing a microservice.

Our Integration Test Strategy 📈

Our testing workflow which in theory was functioning well but in practice was hugely time consuming.

One large pain point were the time consuming integration tests that had to be run before a new feature could be merged to a release branch. These tests ran HTTP requests towards our REST API and made sure that the response was ok for each endpoint. In the monolith days we would spin up the entire monolith for the feature branch and run the tests each night. This would then mark the PR as approved in GitHub.

That was quite time consuming because of the HTTP overhead and all of the setup of test data required to run the requests. We decided to instead minimize them to only test the happy flow. Unfortunately that sometimes resulted in issues with faulty error messages and requests with non-standard parameters that did not respond according to the specification.

All in all while we were not happy with the performance of these tests we however liked the flow itself. That is why we set out to improve the performance of the tests while keeping the workflow as described in our microservice architecture.

The Breakout 💥

For each new feature that we developed in the monolith we formed a strategy on how to break out the related application component into a new microservice. Once a developer picked up the ticket she/he started developing a new service in a new repository with its own deployment pipeline and no shared code with the monolith. This was fairly time consuming but helped us keep up with the regular feature development in parallel to the microservice transformation work.

How We Supercharged our Testing ⚡

According to our old way of running our tests we had only one option to run our integration tests: Once a PR is created we will simply spin up all our microservices, run the tests on all of them to make sure that they work together and then spin them down again.

However, this would make the tests even more time consuming. Deploying all of the individual services would be more complex and more time consuming than just deploying a single monolith instance. After some thinking we concluded that there is no actual reason to deploy all services when the change is introduced in only one of them. However, sometimes the service to be tested had dependencies to other services. So what to do then? Deploy them anyways?

We researched different solutions to this problem and started investigating using mock APIs instead of the real services. The philosophy behind doing this was as long as the external services respond correctly there is no need for them to be real deployed services. This way we did not have to wait for the external dependencies to deploy and we wouldn't even have to pay for their infrastrucure. We could also control the response structure to catch corner cases and make sure that we have good test data. All this without having to spend time and resources to set it up programmatically before running the tests.

Running mock APIs for the external dependencies also meant that we could run the entire stack locally in a very lightweight fashion. Sometimes you see teams running Docker containers with 40 microservices that are really heavy and tedious to get running. When using lightweight mock APIs without any real infrastructure at all we could run everything locally easily even on weaker workstations. By tweaking the responses during development we could also test edge cases and run the integration tests locally which sped up the feedback loop considerably.

Service Tests vs. End-to-End Tests ⚖️

One challenge that we had was what to mock and what not to mock. Basically we split the tests up into two different suites. One suite we called service tests. These had all external dependencies completely mocked and were required to pass before a new feature was merged. This made sure that the test subject worked when the external services were happily returning the data that we expected.

Illustration of what we call "Service Tests"

End to end tests were the other tier and ran as soon as a feature branch was merged to develop. Here we had a dedicated environment up and running with all the real services fully integrated. If these tests failed (which would be rarely) a developer would try to ship a fix as soon as possible. This made us certain that our fleet worked as it should.

Illustration of what we call "End-to-End Tests"

Tools 🛠️

At first we ran tiny Nodejs applications written in Express as mock APIs. These were quick to set up but did not really scale when we had to manage them individually for all of our services. This meant having to deploy them, keep them in sync with the real services and maintain their infrastructure.

At first we started to look into the different tools available to support our use case. We found many services that could generate simple HTTP responses but not quite what we needed. We wanted something that:

Worked well for microservices with many small APIs
Required as little manual work as possible to set up
Were version controlled
Could be run both locally and hosted mocks in sync
Was easy to keep in sync with the real API

That is why we decided to build our own mocking tool. The initial idea was to configure our mocks through a configuration file that we could manage in the GitHub repositories of each individual service. As soon as you pushed a change to the configuration the mock would update and be ready to use. This way we did not have to spend any time on keeping things in sync and worrying about different versions of the mocks. Each branch and version had its own mock that was always available. Next up was the test data needed to keep the consuming services happy. This was quickly integrated in the configuration file so that we could easily add the test data we needed and generate realistic fake data for the consumers.

This was the start and when we decided to build the public tool that is Mocki today we added features such as realistic test data generation as well as simulated failures and delays. If you are interested in trying out a similar setup head over to our start page to learn more or dive straight into the documentation.

Final Solution 💡

New feature: Service tests tests are run on features once there is a PR up. External dependencies are hosted mocks. This made the test suite a lot faster to finish and they required less setup to get started. By using mock services we are also able to test corner cases with generated test data in the mock.

Feature merged: When merging to develop a new test is triggered with real deployed dependencies. If a test fails here developers are notified in Slack and someone will take a look at it. This makes sure that the service works with all external dependencies being the real deal.

Development: While developing we run the microservice locally integrated to mock services also running locally. Since we no longer required the external dependencies to be up and running to develop features we got an increase in developer productivity. We also no longer needed to spin up our real services locally to test things out. We could simply use our lightweight mocks running locally or the hosted ones which are always available.

Note on costs: Not only did we create higher developer efficiency, we also managed to lower the costs for our environments significantly thanks to the infrastructure cost that we save when not haing to deploy each service for each feature environment.

Further Work 🏗️

Error handling and simulation - We have not utilized Mockis capabilities in error handling and failure simulation yet but that could be something to try out for the future to investigate how our services behave with failing dependencies.
Load testing - Using Mocki it is also possible to simulate delays that you would typically see when a service is overloaded. In the future we will run chaos engineering to see which services are affected most by external dependencies being overloaded and how we can remedy the risk of that affecting our users.

Conclusion

Mock APIs can be utilized to save cost and up developer productivity
There are tools that can help you in your journey to testing microservices efficiently
There are many possibilities to use mock APIs to stress test your application

Thank you so much for taking the time to read this! Feel free to reach out if you have questions or need advice on how to get similar benefits 🚀

How we used Open Data APIs to go from $0 to $2000 MRR within weeks 🚀

Karl Eriksson — Fri, 04 Sep 2020 22:06:09 +0000

Why Should You Read This?

Are you in the process of starting a SaaS, e-commerce store or a local business? Then I think this story can help you develop a strategy to get your first hundred dollars MRR without spending tons of money on marketing. Lets begin.

We Had a Product Without Traffic, What to Do?

One of the first products we developed was an online preparation course for the Swedish SAT test. We created thousands of practice questions, hired math experts to write tutorials and spent a lot of time creating optimized landing pages. However, the traffic never came. This was our start.

At the stage we were at, I think a lot of developers creating their own products give up. Developers can spend an insane amount of time creating a product THEY like. But unfortunately we are not good at selling our products or showing them to users in a way that make them interested.

We started thinking what people actually search for in regards to the Swedish SAT and college education. After doing some analysis we noticed that a lot of people used search queries like:

What SAT score is required to get into Law at Stockholm university?
What SAT score is required to get into any Law school in Sweden?
What SAT score is required to get into Computer Science at Linköping university?
Which education in Sweden was the hardest to get into?
Which education had the most applications 2015?

You see these are all related to education. And we figured out that a lot of people searching for these things are interested in improving their SAT test score. So how did we use this? We could have started writing articles like crazy about each education programme, but that would be really time consuming. Instead we approached the problem like developres and started to look at how we could actually generate one page with this kind of data for each education in Sweden.

Open Data APIs - the Golden Egg 🥚

This is where things start to become interesting. Open data APIs! At Mocki we are very supportive of governments and organizations opening up their data publicly. It's an amazing way to let normal companies or people develop applications that never would have been developed otherwise. Our interest in open data started that day when we got our hands on application data for every education in Sweden.

For a specific education programme we were able to see

The number of applicants.
The number of accepted people.
The required SAT score to get accepted.
The percentage of women/men
The percentage of Swedish/Non-Swedish people.
And a lot more...

Suddenly we were able to answer all the questions mentioned earler. We also realised that we could create a website out of this. So that's what we did. At that time there wasn't much competition for these search queries either which was great.

This is a screenshot of some of the data for med school and Lund University. One of the most popular universities in Sweden. It may be hard for a non Swede to understand what the data means. But that's not important here. The important thing is that we created pages with hundreds of words, graphs and tables all automatically generated.

Could This Be Considered Spam?

If you use this tactic in the wrong way with randomized data or just non useful information it's not good. But we knew that this was data people really wanted to find! All the generated texts were useful and provided great user value. And modern day search engine optimization really comes down to providing great value for a user.

This was all confirmed when Google started picking up the pages and loved them. We quickly started ranking on all sorts of keywords related to SAT. In just a couple of weeks we reached traffic numbers of around 10 000 users per month and it kept steadily increasing each day. All user metrics were amazing. Long average time spent on page and many interactions with the graphs. We also noticed people visiting several different pages because they got hooked on seeing all the different graphs we provided.

The Final Step

So we had suddenly created our own traffic source with relevant users. We started putting up banners on the site with the SAT data leading directly to our SAT prep SaaS. The results were great! We got a lot of signups and had to go back working on our course platform since the users discovered bugs and other problems. But we now had a steady flow of new paying customers. That's where you want to be because that is when a SaaS becomes fun.

How Can You Use Open Data Apis to Do the Same?

This strategy may not be applicable for every service out there. But I will try to create one other example where I think this could work.

Lets say you own a snow shoveling business and you are currently expanding to a lot of different cities. Then I think you could combine this strategy with using local SEO.

Use an open API to get all cities in your country with more than x amount of people
Try to find some weather API providing detailed data about if its going to snow
Try to find historical snow data for every city.

So what can we do with with this data? We can generate something like the following text

"What is the snow situation town X right now? - Snow shoveling forecast",

"Town with X with Y inhabitants usually has around Z number of snow days per year. The temperature in September to February is between K degrees. On our snow and ice scale town X has the score of S (scould be calculated by an algorithm that you create). You will probably have to shovel snow around D days per winter."

"It's currently heavily snowing in town X, so be prepared to shovel snow the next D days."

Each page would be both useful and kind of unique. It's important to make sure to have enough variables as Google might think its duplicate content otherwise. When you have created these pages you now have a local snow shoveling page for a lot of cities. Put up your phone number or a link to your booking system and start scaling your snow shoveling business.

There are probably a lot of better examples, but I hope I gave you enough to get thinking :)

Create an Open API and Start Sharing Your Data!

If you are a government, organization or just a company with some great data set you should think about sharing it. In some cases the data is your business and then it's of course not the best idea. But in a lot of cases there is not much to lose. In Scandinavia where Mocki is founded the governments are currently doing great efforts to make data publicly available. There are a lot of applications that will never be developed by governments and state organizations but that companies or hobby programmers would love to create.

Lets say your government would release all the data on every traffic accident in your country, including the location and severity. Then you could create an app warning about historically dangerous roads. It's these types of things that become possible when the data is released to the public.

With Mocki it's very easy to create a simple API with mock data or real data. You can for example use Mocki if you want to make some of you data available to a hackathon or other event. It's a good and safe start as you wouldn't need to expose any of your own infrastructure or sensitive data sources. If that sounds interesting you can sign up with GitHub or send us a message at Mocki.io.

Cheers!

Hosting a Hugo site on AWS S3 and CloudFront

Karl Eriksson — Fri, 27 Mar 2020 16:50:39 +0000

In the early days we used Wordpress as our go-to-CMS. Over the years however we have seen examples of these blazing fast lightweight sites built on top of static site frameworks such as Hugo. These sites had the following advantages over Wordpress:

Super fast (no server side logic at all)
Secure (there is no login system to brute force - it's just static files)
Easy to version control
Easy and cheap to host (no need for a database or backend hosting)

So for the site you are looking at right now (Mocki.io) we chose to go with Hugo. We picked it up quickly and started building out the site still amazed at the speed it serves content. There were however some challenges. Our tech stack is hosted 100% on AWS and we quite like it. Naturally, we chose to deploy this site to AWS as well and the clear choice was S3 which is a static file hosting service. For CDN we chose AWS CloudFront which is super powerful. Deploying the site was quick and S3 + CloudFront served the content at blazing speed.

Of course there were challenges... our previous site did not have trailing slashes in the URL (example.com/page) while Hugo forced us to have trailing slashes (example.com/page/). For SEO reasons we wanted the exact same URL structure as the previous site. When looking in the Hugo documentation it did not have support for that. We also wanted to redirect www.example.com to example.com to make sure there was only one domain you could reach our site on.

To solve this we used Lambda@Edge. An AWS Lambda function is a piece of code that is deployed and run in the cloud. Lambda@Edge is a Lambda function that you can trigger when someone accesses your site through CloudFront. So we wrote a Lambda that removes the trailing slash and redirects the www domain to the non www domain. It also routes the requests from CloudFront to S3 so that the correct HTML-file is fetched from S3.

We put the entire setup in a CloudFormation template that you can deploy in one single command. You can access the code to deploy your own Hugo site on AWS here: https://github.com/keaeriksson/hugo-s3-cloudfront.

The result solved most of our SEO challenges that we had while still keeping the advantages of building the site with Hugo.

Feel free to reach out if you need more advice on hosting static sites on AWS using the chat in the bottom right.

Cheers!

Mocking AWS DynamoDB

Karl Eriksson — Wed, 18 Mar 2020 20:11:54 +0000

We all love living in the cloud, right? Yes we do! As long as we have an internet connection and the services in the cloud are available and accessible.

At times we do not want to rely on having access to cloud services. For example when developing locally or when running tests that should only verify the behaviour of our application and not the behaviour of its external dependencies. In this guide I will show you how you can mock the DynamoDB API so that you no longer need access to the internet or AWS itself while developing.

Let's start off with a simple example where we interact with DynamoDB to fetch some data from a table.

const AWS = require('aws-sdk');

// Use our mock DynamoDB API instead of AWS
AWS.config.dynamodb = { endpoint: 'http://localhost:3001', region: 'eu-west-1' };

const dynamoDbClient = new AWS.DynamoDB.DocumentClient();

dynamoDbClient.get({TableName: 'TasksTable', Key: 'someTask'})
    .promise()
    .then(result => {
        console.log(result.Item)
    });

Assuming that there is a table called TasksTable with an item that has the key Gardening we should see something like the following print:

{ Type: 'Gardening', Description: 'Mow the lawn', DueDay: 'Saturday' }

Now we want to create a mock version of DynamoDB that we can use locally.

To do this we will use Mocki that will help mock the API. Install the tool in your project to get started:

npm install mocki --save-dev

Next up we will create a configuration file that we will call dynamo-mock.yml. This will define the mocked DynamoDB service and its responses. Use the below configuration or set up your own by referencing the documentation.

name: dynamodb-mock
port: 3001
endpoints:
  - path: /
    method: post
    behavior: conditional
    responses:
      - statusCode: 200
        condition:
          operator: eq
          comparand: headers.x-amz-target
          value: DynamoDB_20120810.GetItem
        body:
          Item:
            Type:
              S: Gardening
            Description:
              S: Mow the lawn
            DueDay:
              S: Saturday
        headers:
          - name: content-type
            value: application/json

This will return the object that we expect to get from Dynamo.

Run your mock by running the following command in your project directory: npx mocki run --path dynamo-mock.yml.

When that is running we can change our code to point to the mock instead of AWS service by modifying our code like this:

const AWS = require('aws-sdk');

// Use our mock DynamoDB API instead of AWS
AWS.config.dynamodb = { endpoint: 'http://localhost:3001', region: 'eu-west-1' };

const dynamoDbClient = new AWS.DynamoDB.DocumentClient();

dynamoDbClient.get({TableName: 'TasksTable', Key: 'Gardening'})
    .promise()
    .then(result => {
        console.log(result.Item)
    });

This will point the AWS SDK to our mock instead and run the requests to that instead of the real DynamoDB service.

Let's try it out by running the code and you should get the same result as when we started out. However this time we are not interacting with AWS at all, everything is happening locally and without HTTP calls over the internet. Pretty cool, huh?

It is possible to use the same approach for mocking out all of the AWS services. Under the hood they are all just regular APIs accessed with HTTP requests. In coming articles I will guide you through mocking many more of AWS and other cloud services. Stay tuned!

Why GraphQL is the new REST

Karl Eriksson — Mon, 10 Feb 2020 15:18:35 +0000

Today most web services that I interact with in my work as a developer follow the REST standard (as close as they can). All is usually fine interacting with a REST service as long as there is proper documentation available. Usually working for enterprise client however you will be happy if you receive it in a PDF-file within days of starting to integrate the service...

After getting your hands on a reasonably fresh copy of the documentation you are free to POST, PUT, GET and DELETE away as long as the service is functional.

So - what is the problem I have with REST you might think?

I asked a GraphQL worshipping senior developer on one of my first consulting gigs what advantages it has over REST. My brain was going something like: REST works, REST is widely used, REST is simple, there are many tools that support and... well it's not SOAP at least. His response was something along the lines of "everything". I usually avoid listening to someone who is that uncompromising about something so I figured I would at least investigate it when I had the time.

A few months passed and a new side project idea dawned on me (as they do a couple of times a year). I was going to build a mock API tool. It was going to be great. It was going to be GraphQL.

So as I set out to build something with this magical new tool the truth slowly dawned on me. This is what is going to replace REST. Okay let's not wait any further here is why:

1. Fetch related data on demand

GraphQL enables you to fetch the related data you want in only one HTTP call. Let's say you have a movie database API and want to fetch the movie and the actors in the movie. In REST that might look something like:

GET /movies/star-wars
and then
GET /movies/star-wars/actors

Two HTTP calls => more overhead.

In GraphQL you would execute something like the following query:

{

  getMovie(id: "star-wars") {
    releaseDate
    name
    actors {
      name
    }
  }
}

A single HTTP call. Possibility to fetch related data as many levels down as you want.

2. Automated documentation

As mentioned before documentation is in my opinion key to interacting successfully with a REST API. What is the path? Which method? What query parameters can i pass in? How should the body look like? What headers should I pass?

Of course there are tools that make beautiful documentation for REST APIs that makes this very clear. However it takes work for developers to create that type of beautiful documentation. Time that many of us do not have. That is the way you end up with a PDF file sent a couple days to late over email.

In GraphQL you will get automated documentation that you can use to explore and experiment with the API through a GUI such as GraphiQL which you can check out here.

3. Built in validation and type checking

In a REST API you will have to choose a library to handle your input validation. Or worse yet invent your own. In GraphQL you define your schema and types and both the server and client side validation is handled for you. This is an example of a type:

type Movie {
  name: String!

}

The name property is of type String and hence the ! it is required. This means the server will stop incoming requests which does not contain a name and that consuming clients will stop outgoing requests. Neat.

4. Effective caching

Using libraries such as Apollo on the frontend there is built in smart caching mechanisms that make sure you do not fetch anything unless it has been updated. Let's say you log in to your application and thereby fetch the user logging in in an API call. Instead of re-fetching the user from the API on each page reload Apollo will cache the user until you update it, for example change the email address.

5. It keeps evolving

GraphQL is a growing ecosystem and the community around it is great. It is still young and will keep improving over the coming years.

Conclusion

These are the top five reasons I think GraphQL wins over REST. However as I mentioned I avoid listening to people who see the world in black or white so I still don't think it might be worth it starting to rip out REST at every place you see it from now on. I do think however that you should give GraphQL a try and maybe some day you will find the perfect use case for it.

Let me know if you have a GraphQL project that you want to share!