
In this post I would like to show how to build a GraphQL API server with [gql](https://github.com/deno-libs/gql).
At the moment there are a few GraphQL server modules for Deno, such as [obsidian](https://github.com/open-source-labs/obsidian) and [oak_graphql](https://github.com/aaronwlee/oak-graphql) but all of them are either standalone or framework-specific.
gql instead, is a framework-agnostic middleware so I will use it with Deno std's `http`.

## GraphQL Schema

We'll start with declaring a schema using type definitions and resolvers using [graphql_tag](https://github.com/deno-libs/graphql-tag) and [graphql_tools](https://github.com/deno-libs/graphql_tools) Deno modules, similar to how you do it with Apollo Server or GraphQL Yoga:

```ts
import { makeExecutableSchema } from 'https://deno.land/x/graphql_tools/mod.ts'
import { gql } from 'https://deno.land/x/graphql_tag/mod.ts'

/* Type definitions */
const typeDefs = gql`
  type Query {
    hello: String
  }
`

/* Resolvers */
const resolvers = {
  Query: {
    hello: () => `Hello World!`
  }
}

const schema = makeExecutableSchema({ resolvers, typeDefs })
```

Now we have an executable schema that can be passed to a GraphQL server.

## Server setup

In order to setup gql you just need to pass a `req` object to it so it can read request body and properties.

```ts
import { serve } from 'https://deno.land/std@0.90.0/http/server.ts'
import { GraphQLHTTP } from 'https://deno.land/x/gql/mod.ts'
import { makeExecutableSchema } from 'https://deno.land/x/graphql_tools/mod.ts'
import { gql } from 'https://deno.land/x/graphql_tag/mod.ts'

const typeDefs = gql`
  type Query {
    hello: String
  }
`

const resolvers = {
  Query: {
    hello: () => `Hello World!`
  }
}

const schema = makeExecutableSchema({ resolvers, typeDefs })

const s = serve({ port: 3000 })

for await (const req of s) {
  req.url.startsWith('/graphql')
    ? await GraphQLHTTP({
        schema,
        graphiql: true // enable GraphQL playground
      })(req)
    : req.respond({
        status: 404
      })
```

Now run the server with these permissions (for reading body and using network):

```sh
deno run --allow-net --allow-read server.ts
```

## GraphQL Playground

Now when then server is up, the GraphQL Playground will launch as well.

Open your favourite browser on [http://localhost:3000](http://localhost:3000) and you will see this:

![playground image](https://user-images.githubusercontent.com/35937217/112218821-4133c800-8c35-11eb-984a-5c21fa71c229.png)

## Server Context

It's also possible to pass request context to a schema so it could be used in resolvers.
Request object is automatically passed to the context function.

```ts
import { serve, ServerRequest } from 'https://deno.land/std@0.90.0/http/server.ts'
import { GraphQLHTTP } from 'https://deno.land/x/gql/mod.ts'
import { makeExecutableSchema } from 'https://deno.land/x/graphql_tools/mod.ts'
import { gql } from 'https://deno.land/x/graphql_tag/mod.ts'

const typeDefs = gql`
  type Query {
    hello: String
  }
`

const resolvers = {
  Query: {
    hello: (root, args, ctx) => `Hello World from ${ctx.url}! Cusotm context property ${ctx.ctxProp}`
  }
}

const schema = makeExecutableSchema({ resolvers, typeDefs })

const s = serve({ port: 3000 })

for await (const req of s) {
  req.url.startsWith('/graphql')
    ? await GraphQLHTTP<ServerRequest>({
        schema,
        graphiql: true // enable GraphQL playground,
        context: (request) => ({
          request, // request object
          ctxProp: 'ctxValue' // aditional context properties
        })
      })(req)
    : req.respond({
        status: 404
      })
```

## Conclusion

This is how you can set up a simple GraphQL server for Deno without any backend frameworks, just `std/http`.
Although, there are a few examples of using gql with other frameworks, [check them out](https://github.com/deno-libs/gql/tree/master/examples).


Building a GraphQL API with Deno and gql

In [Deno 1.4](https://deno.land/posts/v1.4) a new flag `--coverage` for `deno test` was added to collect test coverage.
In [Deno 1.8](https://deno.land/posts/v1.8) support for lcov format was shipped, meaning that we can now easily setup coverage report services.
In this tutorial I will show how to configure [Codecov](https://codecov.io) and [Github Actions](https://github.com/actions) for online coverage report.

## Writing tests

Deno provides a convinient built-in API for writing tests.
It also has a [special standard module](https://deno.land/std@0.89.0/testing) for testing that includes assertion functions and benchmarking.

Let's write a simple test:

```ts
// sum_test.ts
import { assertEquals } from 'https://deno.land/std@0.89.0/testing/asserts.ts'
import { sum } from './sum.ts'

Deno.test({
  name: 'sum(a + b)',
  fn: () => {
    assertEquals(sum(2, 3), 5)
  }
})
```

If you are used to Jest-like testing you might try [Wizard](https://github.com/deno-libs/wizard):

```ts
// sum_test.ts
import { sum } from './sum.ts'
import { describe, it, expect, run } from 'https://deno.land/x/wizard/mod.ts'

describe('A test suite', () => {
  it('should sum a + b', () => {
    expect(sum(2, 3)).toBe(5)
  })
})

run() // Start test runner
```

To run the test type this in the terminal:

```sh
deno test
```

## Generating coverage

To produce the coverage files from tests you need to use `--coverage` and `--unstable` (because it is still an experimental feature) flags for the `deno test` command:

```sh
deno test --unstable --coverage=coverage
```

This will create a set of coverage files in the `coverage` folder.
You can pick any folder as the coverage output by specicyfing it with the `--coverage` flag.

Next, we need to generate a coverage report so services like Codecov will be able to consume it:

```sh
deno --unstable coverage ./coverage --lcov > coverage.lcov
```

After running the command a new file "coverage.lcov" will get created.

We created the coverage locally but it doesn't get uploaded anywhere for now.

## Codecov

For online coverage report we will use [Codecov](https://codecov.io/).
Sign up there and open the URL with your repository address:

```url
https://app.codecov.io/gh/<user>/<repo>
```

Later Codecov will know that this repo has been initiated before for coverage upload.

## GitHub Actions

As the CI I'll be using GitHub Actions because it already has a premade [Deno action](https://github.com/denolib/setup-deno) and is easy to configure.

The config looks something like this:

```yml
name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [master]
  pull_request:
    branches: [master]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: denolib/setup-deno@v2
        with:
          deno-version: v1.8
      - name: Create coverage files
        run: deno test --unstable --coverage=coverage # create coverage files
      - name: Create coverage report
        run: deno --unstable coverage ./coverage --lcov > coverage.lcov # create coverage report
      - name: Collect coverage
        uses: codecov/codecov-action@v1.0.10 # upload the report on Codecov
        with:
          file: ./coverage.lcov
```

Create a file called `ci.yml` or `main.yml` with these contents and put it in the `.github/workflows` folder in your repository.
This will trigger GitHub to use their CI.

After pushing that file Github Actions will start running.

Congrats! Now you have continious test run and coverage report.

## Badges

For convinience you may also add badges as indicators:

[![](https://img.shields.io/github/workflow/status/talentlessguy/tinyhttp/CI?style=flat-square)](https://github.com/talentlessguy/tinyhttp-deno/actions) [![](https://img.shields.io/codecov/c/gh/talentlessguy/tinyhttp-deno?style=flat-square)](https://codecov.io/gh/talentlessguy/tinyhttp-deno)

```markdown


[![](https://img.shields.io/github/workflow/status/<user>/<repo>/CI?style=flat-square)](https://github.com/<user>/<repo>/actions)



[![](https://img.shields.io/codecov/c/gh/<user>/<repo>?style=flat-square)](https://codecov.io/gh/<user>/<repo>)
```

## Useful Links

- [Deno manual](https://deno.land/manual/testing#test-coverage)
- [std/testing](https://deno.land/std@0.89.0/testing)

## Conclusion

Despite that coverage tooling in Deno is relatively new, it's already possible to set the full toolchain up with no hassle.
Notice that it's all done by the Deno CLI commands, unlike Node, where you have to (at least) install `c8` and `uvu` for tests and coverage report.

Test coverage in Deno with Codecov and GitHub Actions


## Introduction

After spending an hour on trying to figure out how to protect specific GraphQL query objects in Nexus from unintended access (e.g. querying other users than you) I finally found a simple, yet effective solution.
I would like to share it with others and for myself in case I face this problem again.

I was building a fullstack application with Next.js, Prisma, GraphQL and Nexus. When I needed to implement query objects for user data I noticed that I could easily query other users data using `user(where: { id : "x" })` and I didn't want to leak user data this way.
So, I started googling and only found parts of the solution or irrelevant code samples.

This is what I've read through:

- https://github.com/graphql-nexus/nexus-plugin-prisma/issues/600
- https://nexusjs.org/docs/plugins/field-authorize
- https://github.com/nextauthjs/next-auth/discussions/536
- https://github.com/graphql-nexus/nexus-plugin-prisma/issues/611
- https://github.com/graphql-nexus/nexus-plugin-prisma/issues/598

After some hacking I came up with the solution combined from all those threads and now I would like to share it.

## Dependencies and configurations

1. Install all required dependencies:

```sh
pnpm i next react react-dom graphql prisma nexus nexus-plugin-prisma nexus-shield apollo-server-micro next-auth && pnpm i -D typescript @types/node @types/react @types/next-auth
```

2. Add a few npm scripts for Prisma client and types generation:

```json
{
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "NODE_ENV=production next start",
    "client": "prisma generate",
    "migrate": "prisma migrate dev --preview-feature",
    "generate:nexus": "ts-node --transpile-only -P nexus.tsconfig.json pages/api/graphql.ts",
    "generate:prisma": "prisma generate",
    "generate": "npm run generate:prisma && npm run generate:nexus",
    "postinstall": "npm run generate"
  }
}
```

3. Create TypeScript configurations for our Next.js app and Nexus

**tsconfig.json**:

```js
{
  "compilerOptions": {
    "target": "ES2019",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "preserveSymlinks": true,
    "baseUrl": ".",
    "paths": {
      "*": ["./*"]
    },
    "plugins": [
      {
        "name": "nexus/typescript-language-service"
      }
    ],
    "module": "ESNext"
  },
  "include": ["**/*.ts", "**/*.tsx", ".", "types.d.ts"],
  "exclude": ["node_modules"]
}
```

**nexus.tsconfig.json**

```js
{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "sourceMap": true,
    "outDir": "dist",
    "strict": true,
    "lib": ["esnext"],
    "esModuleInterop": true,
    "module": "CommonJS"
  }
}
```

You can also optionally add a GraphQL configuration file (`graphql.config.js`) for better editor support:

```js
module.exports = {
  schema: 'generated/schema.graphql'
}
```

## Database and Prisma

You can read how to prepare the database for Prisma and setup Prisma itself in [this tutorial](https://dev.to/prisma/passwordless-authentication-with-next-js-prisma-and-next-auth-5g8g).

Take in consideration that you already have Prisma installed via `prisma` instead of `@prisma/cli` (which is deprecated now).

After creating the schema, run the command to generate the Prisma client:

```sh
pnpm generate:prisma
```

Then reload your editor so the Prisma client will be typed.

After that, create a prisma client instance that will be shared between libraries:

```js
// lib/prisma.ts
import { PrismaClient } from '@prisma/client'

export const prisma = new PrismaClient()
```

As for now, Prisma is ready. Let's switch to other libraries next.

## Tweaking next-auth

The next library we will set up is going to be [next-auth](https://next-auth.js.org/). The config looks like this:

```js
// lib/auth.ts
import Providers from 'next-auth/providers'
import Adapters from 'next-auth/adapters'
import { prisma } from './prisma'

const options = {
  adapter: Adapters.Prisma.Adapter({ prisma }),
  site: process.env.SITE || 'http://localhost:3000',
  callbacks: {
    // Assign user ID to current session object
    session: async (sess, u) => {
      sess.id = u.id

      return Promise.resolve(sess)
    }
  },
  // Configure one or more authentication providers
  providers: [
    Providers.GitHub({
      clientId: process.env.GITHUB_ID,
      clientSecret: process.env.GITHUB_SECRET
    })
  ]
}

export default options
```

The config is very similar to the one that tutorials describe with one significant change.
We register a custom callback that assigns the current user ID to user session object.
This way we can identify what ID our user has, compare it on server side and give only the user owned data.

## GraphQL

Due to unstability of Prisma it's components gets either deprecated or revived from time to time.
The article was written at 22/02/21, maybe in the future the way to set things up will change.

### Apollo server

The easiest part is setting up a GraphQL endpoint. It's the same as any other Next.js API function:

```js
import { ApolloServer } from 'apollo-server-micro'
import { schema } from '../../graphql/schema'
import { createContext } from '../../graphql/context'

const apolloServer = new ApolloServer({
  context: createContext,
  schema,
  tracing: process.env.NODE_ENV === 'development'
})

export const config = { api: { bodyParser: false } }

export default apolloServer.createHandler({ path: '/api/graphql' })
```

### Schema generator

The entrypoint of a GraphQL server is a schema. Thanks to Nexus we can generate schema instead of hand-writing it. Additionally we will generate typings for better editor support:

```ts
// graphql/schema.ts
import { makeSchema } from 'nexus'
import { nexusPrisma } from 'nexus-plugin-prisma'
import path from 'path'
import { Mutation, Post, Query, User } from './resolvers'
import { nexusShield, allow } from 'nexus-shield'
import { ForbiddenError } from 'apollo-server-micro'

export const schema = makeSchema({
  types: [Query, User, Post, Mutation],
  contextType: {
    module: path.join(process.cwd(), 'graphql', 'context.ts'),
    export: 'Context'
  },
  plugins: [
    nexusPrisma({
      experimentalCRUD: true,
      outputs: { typegen: path.join(process.cwd(), 'generated', 'typegen-nexus-plugin-prisma.d.ts') }
    }),
    nexusShield({
      defaultError: new ForbiddenError('Not allowed'),
      defaultRule: allow
    })
  ],
  outputs: {
    typegen: path.join(process.cwd(), 'generated', 'nexus-typegen.ts'),
    schema: path.join(process.cwd(), 'generated', 'schema.graphql')
  }
})
```

As you see here, we use a [nexus-shield](https://github.com/Sytten/nexus-shield) plugin. With the help of this plugin we can set custom rules for specific resolvers.

### Context

Context is required for adding custom logic for query objects resolution. In our case, we put the Prisma client and session object into context.

```ts
// graphql/context.ts
import type { PrismaClient } from '@prisma/client'
import { IncomingMessage } from 'http'
import { getSession, Session } from 'next-auth/client'
import { prisma } from '../lib/prisma'

export interface Context {
  prisma: PrismaClient
  session: Session
}

export const createContext = async ({ req }: { req: IncomingMessage }): Promise<Context> => {
  const session = await getSession({ req })

  return { prisma, session }
}
```

### Resolvers

Finally, we reached the place where we handle data resolution for our GraphQL server.

```ts
import { mutationType, objectType, queryType } from 'nexus'
import { ruleType } from 'nexus-shield'

export const Query = queryType({
  definition(t) {
    t.crud.user({
      shield: ruleType({
        resolve: (_, args, ctx) => ctx.session.id === args.where.id
      })
    })
  }
})

export const User = objectType({
  name: 'User',
  definition(t) {
    t.model.id()
    t.model.name()
    t.model.image()
  }
})
```

This is where we check for current user ID and compare it to the ID that we got from the session.
This kind of protection will not allow users with different IDs to request other users.

## Fetch on the client

We implemented the server logic for making users request only their own data.
Now we need to fetch data from the GraphQL endpoint using our session ID.

```js
// pages/index.tsx
import React from 'react'
import { gql, useQuery } from '@apollo/client'
import { useSession } from 'next-auth/client'

const Page = () => {
  const [sess] = useSession()
  const { data } = useQuery(
    gql`
      query userInfo($id: Int!) {
        user(where: { id: $id }) {
          id
          name
        }
      }
    `,
    { variables: { id: sess?.id } }
  )

  return <>{JSON.stringify(data)}</>
}

export default Page
```

We obtain session ID that we passed before and put it to query variables.
Then on backend the User resolver compares those IDs and if they match, sends the requested data.
You can test it on other IDs and you will get "Not Allowed" error.

## Conclusion

Despite the ease of auth protection, there's still no good articles covering this topic.
There is a lot of "quick-start" ones but none of them describes the auth flow.
I hope my article saved you time that you would have to spend on the same research I did.


Nexus + Prisma resolver auth in Next.js


After months of hard work I'm thrilled to present the first major (1.0) release of [tinyhttp](https://github.com/talentlessguy/tinyhttp), a 0-legacy, tiny and fast web framework which aims to replace Express for modern Node.js environments.

## What is tinyhttp

A few months ago I wrote an [introduction post](https://dev.to/talentlessguy/meet-tinyhttp-a-0-legacy-tiny-and-fast-alternative-to-express-4m92) to tinyhttp, but if in short, it's an Express-like web framework that tries to be as minimal as possible by relying on modern runtime and language features instead of dozens of polyfills and deprecated APIs.

tinyhttp apps look almost the same as Express ones, for example:

```js
import { App } from '@tinyhttp/app'
import { logger } from '@tinyhttp/logger'

const app = new App()

app
  .use(logger())
  .use(function someMiddleware(req, res, next) {
    console.log('Did a request')
    next()
  })
  .get('/', (_, res) => {
    res.send('<h1>Hello World</h1>')
  })
  .get('/page/:page/', (req, res) => {
    res.status(200).send(`You just opened ${req.params.page}`)
  })
  .listen(3000)
```

You probably noticed that instead of `require`, here we use ESM imports. tinyhttp is recommended to be used with ["Native ESM"](https://nodejs.org/api/esm.html), a module system of the ECMAScript spec implemented for Node.js.

Unlike Express, tinyhttp is compiled to _both_ ESM and CommonJS module systems, while still being much smaller than Express.

tinyhttp also targets the latest LTS runtimes, such as Node 12 and newer, to achieve the smallest package size and avoid using polyfills for language features that are already present in JavaScript.

The [project repository](https://github.com/talentlessguy/tinyhttp) contains a lot of examples of using tinyhttp with other technologies, such as ORMs, databases, authentification libraries, etc.

## What's new in 1.0

There are a few important additions since the 0.5 release, such as custom `req` / `res` extensions and catching async errors.

### Custom middleware extensions

With the new `applyExtensions` parameter you can define your own req / res extensions, or disable all tinyhttp's extensions to achieve the best performance.

```js
import { App } from '@tinyhttp/app'
import { send } from '@tinyhttp/send'

const app = new App({
  applyExtensions: (req, res, next) => {
    // now tinyhttp only has a `res.send` extension
    res.send = send(req, res)
  }
})
```

### Catching errors in async handlers

Errors thrown in async handlers are now catched and passed to next, e.g. if an error is throwed in a handler it won't crash and will keep working.

Example:

```js
import { App } from '@tinyhttp/app'

const app = new App()

app.use(async (_req, _res) => {
  throw `error`
})

app.listen(3000)
```

The app will return the error and send 500 status:

```sh
$ curl localhost:3000
error
```

### Other changes

- Code coverage increased up to 92%
- Every submodule of tinyhttp doesn't strictly depend on `IncomingMessage` and `ServerResponse` anymore. Only the used properties are required, meaning that these packages are more flexible and can be used in other runtimes.
- A few bug fixes in `@tinyhttp/router` and other packages

tinyhttp is also open for contributions! Read the [guide](https://github.com/talentlessguy/tinyhttp/blob/master/CONTRIBUTING.md) to get started.


Presenting tinyhttp 1.0 - a 0-legacy, tiny & fast web framework as a replacement of Express, written in TypeScript.


## Intro

Recently, Go 1.12 released. Go now has a great WebAssembly support, even a special UMD script for better DX.

So, if we have WebAssembly, it means that we can access DOM.
Go even has a special package for that – `syscall/js`.
It basically just gets / sets global objects or calls functions.
So, to avoid writing ugly `Call()` & `Get("document")` code, we'll be using [godom](https://github.com/siongui/godom/tree/master/wasm), a library with predefined shortened functions.
It is mostly used for [GopherJS](https://github.com/gopherjs/gopherjs) (Go to JS compiler), but has WebAssembly support as well.

## Requirements

- [go 1.12+](https://golang.org/dl/)
- Firefox 68 (was used during writing the article) / Chrome 69 / any other browser that supports WebAssembly

## Let's code!

### Glue

Let's create glue.js and index.html to make WebAssembly work.
Even though WASM is _magic_ that runs natively it still needs some glue to load itself.

**index.html**

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Go frontend app</title>
    <script src="wasm_exec.js"></script>
    <script src="glue.js"></script>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>
```

Here we attached two scripts and added a target container.

Don't forget to copy `wasm_exec` script!

```sh
cp $(go env GOROOT)/misc/wasm/wasm_exec.js
```

**glue.js**

```js
const go = new Go()
WebAssembly.instantiateStreaming(
  fetch('app.wasm', {
    headers: {
      'Content-Type': 'application/wasm'
    }
  }),
  go.importObject
).then(result => go.run(result.instance))
```

In our glue code, we created an instance of a special Go class for better error messages and some setup especially for Go, launched a WebAssembly stream using fetch (e.g. wasm module loads asynchronously), created a new WebAssembly instance, and ran it.

Our frontend setup is done. Let's do some stuff with Go.

### Go Setup

Init go module:

```sh
go mod init
```

Install godom (wasm package):

```sh
go get -u -v github.com/siongui/godom/wasm
```

### Go Code

At first let's write a simple Hello World markup:

```go
package main

import (
	dom "github.com/siongui/godom/wasm"
)

func main() {
	app := dom.Document.GetElementById("app")
	app.SetInnerHTML(`
	<div>
		<h1>Hello World</h1>
		<p>This page is built with Go, GoDOM and WebAssembly</p>
	</div>
	`)
}
```

As you can see here, we selected our `#app` div defined in an HTML file.
Then we modify a property called ["InnerHTML"](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML).
godom doesn't have a function for every DOM interaction but you can still use `syscall/js` "Call" for such cases.

### Compile Go to WebAssembly

We need to compile our go code to wasm to make it work.
To compile to wasm, we should set system architecture to WASM, and OS to JS.
Those is certainly no real OS called "JS" or processor architecture "WASM".
Go uses them to detect that we want to compile it to WebAssembly instead of building a native executable.

In the terminal run this command:

```sh
ARCH=WASM OS=js go build -o app.wasm index.go
```

Now we have a compiled file. It is called "app.wasm".

The last step is running a server to see the result. There are a few quick options that you can use:

- Using Go [goexec](https://github.com/shurcooL/goexec) package:

```sh
goexec 'http.ListenAndServe(":8080", http.FileServer(http.Dir(".")))'
```

- Using Python:

```sh
python -m http.server -p 8080
```

- Using Node.js and [serve](https://github.com/zeit/serve) module:

```sh
serve -p 8080
```

We see hello world!

<WasmHelloWorld />

### Interactive DOM

It is already very fun to write webpages with `innerHTML` but let's make some more complex stuff. We will attach a handler to a button and also add content with JS.

First, we import `syscall/js` because godom doesn't have some functions we need:

```go
package main

import (
	dom "github.com/siongui/godom/wasm"
	"syscall/js"
)
```

Then we take our container (`#app`), create two elements – `<span>` and `<button>`.

```go
app := dom.Document.GetElementById("app")
button := dom.Document.CreateElement("button")
text := dom.Document.CreateElement("span")
```

Fine, let's add some text to our button.

```go
// Set button text

button.Set("textContent", "Click on me")
```

Now here all the magic happens. We're gonna make a callback handler for click event. `syscall/js` has a special wrapper for JavaScript functions `js.FuncOf` and `Func` is an interface for `FuncOf`.

```go
// Callback for click event
var cb js.Func
cb = js.FuncOf(func(this js.Value, args []js.Value) interface{} {
	text.Set("textContent", "Button was clicked")
	return nil
})

// Add event listener to a button
button.Call("addEventListener", "click", cb)
```

We use an array for JS arguments because in JS we pass them as a simple list of things for functions:

```js
// Small example
const args = (...arguments) => console.log(arguments)
args(0, 1, 2)
```

The last thing we need to do is to append our elements to container:

```go
app.Call("appendChild", text)
app.Call("appendChild", button)
```

But there is one small problem...

```none
 wasm_exec.js:378 Uncaught Error: bad callback: Go program has already exited
     at global.Go._resolveCallbackPromise (wasm_exec.js:378)
     at wasm_exec.js:394
     at <anonymous>:1:1
```

Go program is already finished and it skips our callbacks. Let's fix it.

We don't want Go to exit our program so we have to use [channels](https://tour.golang.org/concurrency/2). We need to put this in the beginning of our main function:

```go
// Create a channel that doesn't let our Go program exit
c := make(chan bool)
```

And in the end we put this:

```go
<-c
```

Now our Go program doesn't exit even with callbacks!

Let's try, it works!

<WasmButtonDemo />

## Conclusion

Although, all the API calls for now are made through JS, the fact that we can now pick other language than JavaScript is impressive.
Probably, in the future, WebAssembly will get it's own DOM API.


My blog

Building a GraphQL API with Deno and gql

Test coverage in Deno with Codecov and GitHub Actions

Nexus + Prisma resolver auth in Next.js

Presenting tinyhttp 1.0 - a 0-legacy, tiny & fast web framework as a replacement of Express, written in TypeScript.

Let's write frontend in Go