GraphQL Mesh Gateway Health Check Endpoint

When running the GraphQL Mesh server in a cloud environment in a container, perhaps using a platform like Kubernetes or Elastic Container Service on AWS, we need to specify an HTTP endpoint to act as a health check for the container.

Though it is not well-documented, the Mesh server does have a healthcheck endpoint available.

The route is simply: /healthcheck

Here is an example calling the healthcheck of a locally running Mesh server:

$ curl "http://localhost:4000/healthcheck" -v
* Connected to localhost (127.0.0.1) port 4000 (#0)
> GET /healthcheck HTTP/1.1
> Host: localhost:4000
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Mon, 19 Dec 2022 03:06:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Content-Length: 0
<

Note that just the root response (“/”) returns an HTTP 302 Found and so /healthcheck is ideal for a 200 OK health status response.

Set a POST Request to be a Query in GraphQL Mesh using OpenAPI

When integrating REST APIs into GraphQL Mesh through the OpenAPI plugin, sometimes we want to specify that a POST path is actually a query and not a mutation.
That is, we need to override the default GraphQL Mesh OpenAPI/Swagger plugin behaviour of assuming that a path with a POST method is a mutation.

In the GraphQL Mesh YAML file (.meshrc.yml) we use the following in the declaration of our example service:

- name: example-service
  handler:
    openapi:
      source: '${EXAMPLE_SERVICE_BASE_URI}/docs'
      baseUrl: '${EXAMPLE_SERVICE_BASE_URI}'
      operationHeaders:
        Authorization: "{context.headers['authorization']}"
      selectQueryOrMutationField:
        - fieldName: 'exampleAction'
          type: Query

Note that fieldName is the value of operationId in the OpenAPI Spec (in this example: ‘exampleAction’).

Version Differences

Important: there was a change in the syntax for this feature in November 2022.

The previous format was as below:

- name: example-service
  handler:
    openapi:
      source: '${EXAMPLE_SERVICE_BASE_URI}/docs'
      baseUrl: '${EXAMPLE_SERVICE_BASE_URI}'
      operationHeaders:
        Authorization: "{context.headers['authorization']}"
      selectQueryOrMutationField:
        - title: 'Example Service Spec'
          path: /v1/example-service/resource
          method: post
          type: Query

Make sure the title is the key in the YAML and matches the exact title in the OpenAPI Spec referenced.

To confirm this works, start the Mesh server and confirm that the operation shows up as a Query instead of a Mutation.

References

https://github.com/Urigo/graphql-mesh/discussions/2921

Run an Ubuntu VM on an Apple M1 Mac

The simplest way to run an Ubuntu Linux virtual machine on a new Apple M1 chip macOS machine is to use Multipass.

First, install Multipass:

$ brew install --cask multipass

There should be a primary VM instance available already.

To start the primary Ubuntu instance:

$ multipass start

It should show:

Starting primary

Show running instances:

$ multipass list

The output should be similar to:

Name    State   IPv4         Image
primary Running 192.168.64.2 Ubuntu 20.04 LTS

Now we can SSH into the VM using:

$ multipass shell

You should see a prompt for the shell inside the Ubuntu VM:

ubuntu@primary:~$

Your Ubuntu VM is now ready to use!

Additionally, to mount a directory to access files from the host machine inside the VM, see this post:

Mount a Host Machine Directory Inside a Multipass VM

Mount a Host Machine Directory Inside a Multipass VM

To be able to access files on a host machine from a Multipass Ubuntu VM, we can mount the local directory into the virtual machine.

Assuming we have a host system directory my-stuff, we can mount it into the VM with:

$ multipass mount my-stuff primary:/home/ubuntu/my-stuff

Note the required name primary which refers to the VM instance name.

Check that the mount shows up correctly in Multipass:

$ multipass info primary

This should show your local and VM directory, with a line similar to:

Mounts: /Users/abc/Documents/my-stuff => /home/ubuntu/my-stuff

SSH into the VM to see the directory:

$ multipass shell
ubuntu@primary:~$ ls my-stuff
file1
file2
...

The directory should now be accessible inside the VM and we can share files between the host machine and VM.

Related Posts

Run an Ubuntu VM on an Apple M1 Mac

Rename a Branch in Git

Sometimes we need to rename an existing Git branch without creating a new branch or removing the old branch.

First, make sure you have the existing branch to rename checked out:

$ git branch

Output:

main
* old-name

To rename the branch use:

$ git branch -m old-name new-name

The command ‘m’ is short for “move”, similar to moving a file to rename it in Unix systems.

Confirm the new name:

$ git branch

Output:

main
* new-name

Open Visual Studio Code from the Terminal on macOS

It is useful to be able to open VSCode from the command line with the code command.

To add this ability, edit your PATH as follows:

PATH=$PATH:/Applications/Visual\ Studio\ Code.app/Contents/Resources/app/bin

Add this to your .bash_profile or equivalent.

This will ensure your shell will find the code binary from VSCode while in any directory.

Now you can open any file in your current working directory with VSCode using:

$ code file.js

Or just open the editor without a file in the current directory:

$ code .

 

Include the Same Query More than Once in a GraphQL Request

It can sometimes be useful to request two or more copies of the same query result in one GraphQL request.

We can repeat the same query twice, for example, using output naming as in the example below:

{
  getBook {
    title
  }

  secondCopy:getBook {
    title
  }
}

The label secondCopy is required to create a unique name in the output data.

The label we use will replace the query name in the output response, as below:

{
  "data": {
    "getBook": {
      "title": "Book A"
    },
    "secondCopy": {
      "title": "Book A"
    }
  }
}

We can request as many copies as desired in the query.

 

Convert OpenAPI YAML File to JSON

We can convert an OpenAPI (or Swagger) specification file into JSON using the yamljs utility.
We can install the binary globally command using:

$ npm install -g yamljs

This should make yaml2json available in the shell. We can then run:

$ yaml2json input.yaml -i4 -p > output.json

The output file is the JSON equivalent of the YAML spec.

The -p param means “pretty” and “-i4” means indentation of 4 spaces.

References

https://www.npmjs.com/package/yamljs

 

 

Create an HTML Test Coverage Report in Go

We can generate a unit test coverage report in Golang using the following commands and tools which are included with the language.

To run unit tests with coverage collection use:

go test -covermode=count -coverpkg=./... -coverprofile cover.out -v ./...

The coverpkg parameter is needed for the code coverage to include packages and not just the top level files in the project directory.

Generate the visual coverage HTML files using:

go tool cover -html cover.out -o cover.html

If you are using a Makefile on macOS we can add a command to run all of this together in order and open the page in a browser:

test-coverage:
  go test -v ./... -covermode=count -coverpkg=./... -coverprofile coverage/coverage.out
  go tool cover -html coverage/coverage.out -o coverage/coverage.html
  open coverage/coverage.html

Then run:

make test-coverage

This will open the very nice coverage report HTML page in a browser.

 

Batch Resources Endpoint in REST API Design

Sometimes in a REST API we want a single endpoint to be able to return multiple types of resources at once.

Some names for this are a batch resources endpoint or simply batch endpoint; another name is bulk endpoint.

The endpoint itself could use the resource name “/batch-resources” or simply “/batch”.

Suppose we have a public library system API. The batch call could look like the following:

GET /batch-resources?list=(/locations,/books,/authors)

The returned result can be organized by resource:

{
  "locations": [
    {
      "id" 1,
      ...
    },
    ...
  ],
  "books": [
    {
      "id": 1,
      ...
    },
    ...
  ],
  "authors": [
    {
      "id": 1,
      ...
    },
    ...
  ]
}

If we need filters or sub-resources we can pass them with the individual resources listed, as if they were individual calls. For example:

GET /batch-resources?list=(/authors?q=term,/authors/1/books)

In this case the results should contain the full request paths and query strings as the keys:

{
  "authors?q=terms": [ ... ],
  "authors/1/books": [ ... ]
}

Although GET feels most natural and is the proper REST verb here, if we need very complex requests all at once in the batch request, we could use a POST request with the specific requests in the POST body. For example:

POST /batch-resources
{
  "requests": [
    "/locations?q=term",
    "/books?q=term",
    "/authors?q=term"
  ]
}

The returned response would again be organized by request key.

Using POST would have the advantage of a much larger potential body for the query; a very large GET request may not be enough when reaching the length limit of the query string.

Note that if you need a very flexible API with batch requests, especially serving many different clients with different requirements, it may be appropriate to consider GraphQL.