There is a lot of keyword in the title but this is not a clickbait, we will setup without too much burden a simple configuration that will allow Visual Studio Code (VsCode) to hook into a GraphQL installation. The idea is that everytime a TypeScript file is saved that automatically the file is transpiled into JavaScript and to have Node reboot. The solution I propose can do the transpilation, the schema transportation and the restart of NodeJS under 2 seconds.

NPM

The first step is to get some NPM packages. The first one is named concurrently which will allow from a single line, a single NPM command to execute multiple commands. This is required to have TypeScript in watch mode, having a file watcher for the GraphQL schemas and restarting node if any of the previous two changes. The second is the package cpx which can watch for file and copy them if something changes. The third is TypeScript that will watch all TypeScript file for changes and build into the output folder. The fourth package is nodemon that monitor changes in file. If a file change, it restart Node.

"concurrently": "^4.1.0",
"cpx": "^1.5.0",
"typescript": "^3.2.2",
"nodemon": "^1.18.8"

Then few NPM scripts are required.

"dev": "concurrently \"tsc -w\" \"npm run watchgraphql\" \"nodemon build/dist/index.js\"",
"debug": "concurrently \"tsc -w\" \"npm run watchgraphql\" \"nodemon --inspect build/dist/index.js\"",
"watchgraphql": "cpx 'src/graphql/schemas/**/*.graphql' build/dist/graphql/schemas/ -w -v"

There are two main scripts. The dev and debug. I mostly run the second one because it does the same as the first one with the addition of opening a port for VsCode to connect to debug the NodeJS (Express) server. What it goes is to start concurrently TypeScript in watch mode (-w), run the watchgraphql and nodemon to watch every file (produced JavaScript and GraphQL schema files. The GraphQL’s schemas have there own extension “.graphql” and are not moved like TypeScript during the transpilation. Hence, it requires a separate process to move the file when we edit the file.

Visual Studio Code

Finally, within Visual Studio you need to create a debug launch configuration. The creation occurs in the fourth button of the menu, the one with a bug. It is possible to select “Add Configuration” in the dropdown to create a new debugging configuration. Here is the one I am using:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to node",
            "type": "node",
            "request": "attach",
            "restart": true,
            "port": 9229
        }
    ]
}

It will attach to an existing instance. It means that if you want to debug the startup of the NodeJS server that it does not work. You will need to change the way to avoid using nodemon and to have the VsCode debugger starting the NodeJS server. It is not a use case that I need, hence I do not have it configured.

Once you have these scripts in place and the VsCode configuration saved. You can click the play button or F5 to start debugging. It takes about 1-2 seconds to hook to the process. Any breakpoint you have set will stop the process and gives you time to explore the variables. If you do a change during the debug, NodeJS will restart and the debugging will stop and restart as well.

HTTP Request Debugging

I am using Axios, but other libraries allow also to shim a proxy to inspect HTTP request and response. It is very valuable when debugging an Apollo GraphQL server because you cannot do like with a web application and use Chrome’s network tab. A trick with Axios is when you configure the AxiosRequestConfig to set a proxy in the HTTP header of the request that point to your computer.

config.proxy = {
    host: "127.0.0.1",
    port: 5555
};

Then, installing a tool like Postman at the specified port is enough to receive every request with the proper HTTP headers in place.

Summary

I am far from being an expert concerning developing server side application with NodeJS. I was impressed of the quick result. Within an hour, I had a development environment that was efficient to develop and to debug. The experience of debugging directly in TypeScript is awesome and to see every request and response swimming through the proxy tool is priceless when it is the time to understand what is coming out and in the GraphQL’s resolvers.

Some other GraphQL articles

• Getting Started with GraphQL for Netflix Open Connect
• Install Apollo Server to host a GraphQL service
• Apollo Server and Secured Playground
• GraphQL Context
• GraphQL Query with Argument
• Apollo GraphQL Resolvers and Data Source separation
• How to setup a TypeScript, NodeJS, Express Apollo Server to easy debugging with VsCode
• GraphQL Resolvers with Apollo
• Configuring Apollo Playground and API on two different URL
• How to automatically generate TypeScript for consumers of your GraphQL