DEV Community: Sebastian Döll

The Power of TypeScript for GraphQL Union Type Filters

Sebastian Döll — Tue, 02 Mar 2021 08:17:41 +0000

GraphQL is great. Code generating types for TypeScript is easy. GraphQL supports introspection. This means a GraphQL API provides information about the described schema.

Using the GraphQL CLI and the GraphQL Code Generator generating types for a graphcms is really handy.

# GraphCMS API
schema: https://api-eu-central-1.graphcms.com/v2/xxxxx/master
overwrite: true
documents: ./src/graphql/**/*.graphql

# Format files

extensions:
  codegen:
    hooks:
      afterAllFileWrite:
        - eslint --fix
    generates:
      ./schema.graphql:
        plugins:
          - schema-ast
      src/generated-types.tsx:
        plugins:
          - typescript
          - typescript-operations
          - typescript-react-apollo
        config:
          withHOC: false
          withComponent: true
          withHooks: true

When you add to it the capability to create types for your queries, this is really powerful. A powerful feature of GraphQL are union type. A field can contain different types. For example a Page or Post can can be returned a reference for another page.

query Layout($slug: String = "home") {
  page(where: {slug: $slug}, stage: PUBLISHED) {
    id
    title
    slug
    content
    refs {
      __typename
      ...on Page {
        createdAt
        publishedAt
        pageSlug: slug
        teaser
      }
      ... on Post {
        title
        excerpt
        createdAt
        publishedAt
      }
    }
  }
}

The generated code of the layout query looks like this.

export type LayoutQuery = { __typename?: 'Query' } & {
  page?: Maybe<
    { __typename?: 'Page' } & Pick<
      Page,
      'id' | 'title' | 'slug' | 'content'
    > & {
        refs: Array<
          | ({ __typename: 'Page' } & Pick<
              Page,
              'createdAt' | 'publishedAt' | 'teaser'
            > & { pageSlug: Page['slug'] })
          | ({ __typename: 'Post' } & Pick<
              Post,
              'title' | 'excerpt' | 'createdAt' | 'publishedAt'
            >)
        >
      }
  >
}

Filtering for a Page or Post in the references is not sound, meaning that the TypeScript compiler can tell which type is filtered. A small helper function can provide the necessary information for the compiler so the filtered values are properly typed.

const guardFactory = <T, K extends keyof T, V extends string & T[K]>(
  k: K,
  v: V
): ((o: T) => o is Extract<T, Record<K, V>>) => {
  return (o: T): o is Extract<T, Record<K, V>> => {
    return o[k] === v
  }
}

A filter on the values then returns a properly typed array of Posts or Pages.

const pages = refs.filter(guardFactory('__typename', 'Page'))

This is a really small helper, but it allows to use the full power of TypeScript and GraphQL.

Composition in Next.js Static Properties

Sebastian Döll — Mon, 01 Mar 2021 13:53:46 +0000

Composition is a method to write re-usable segments of code. This is achieved by constructing objects of full behavior by using objects with particular behavior.

It seems like “composition over inheritance” is the new motto. Everyone’s talking about it, and that’s not strange since composition gives you more flexibility by composing functionality to create a new object, while inheritance forces you to extend entities in an inheritance tree.

In the case of getStaticProps the full behavior is the complete object of props a page needs to be rendered. The particular object is the behavior that fetches a particular property in in the props.

export async function getStaticProps(context) =>
({ ...(await getHeader(context), ...(await getData(context))})

To make this method easier to use, one can write simple helper function.

export type TContext = GetStaticPropsContext
export type TComposeFunction<TProps> = (
  ctx: TContext
) => Promise<TStaticPropsResult<TProps>>
export type TStaticPropsResult<TProps> = GetStaticPropsResult<TProps>

export const compose = <TProps>(...funcs: TComposeFunction<TProps>[]) => {
  return async (ctx: TContext): Promise<TStaticPropsResult<TProps>> =>
    funcs.reduce<Promise<TStaticPropsResult<TProps>>>(
      async (result, fn) => ({ ...result, ...(await fn(ctx)) }),
      Promise.resolve(<TStaticPropsResult<TProps>>{ props: {} })
    )
}

export default compose

Which can use use like this.

export const getStaticProps = compose(getCommonStaticProps, getSpecificStaticProps)

Using Promise.all one can also leverage concurrency in the static props.

The State of Go Plugins

Sebastian Döll — Thu, 18 Feb 2021 09:27:55 +0000

Terraform, Protocol Buffers, Waypoint or Traefik have build a flourishing ecosystem by using the Go programming language and providing pluggable interfaces. But, not all pluggable interfaces in Go are created equal. There is more than one solution to the problem.

The problem they all try to solve is, that Go is a statically typed, compiled programming language. Thus, executing and interacting with code beyond the build phase of a Go program is hard. The progress of the standard library plugin package has also been very slow in recent years.

These are the common solutions to the problem out in the wild.

Client-server
Stdin to Stdout
Dynamic interpretation
Dynamic libraries with symbol resolution

Client-Server

This is perhaps the most common approach to pluggable interfaces in Go. Terraform or Waypoint use this approach. How does this works?

Plugins are standalone Go programs (executables) that the main program executes. The main program runs a server that the plugin can connect to when run. The connection information are passed to the plugin as parameters or environment variables. Client and server commonly communicate via gRPC. Which allows for efficient communication, sharing the used interface and code generate client and server boilerplate.

The client-server communication via HTTP/2 has an impact on performance. If you want to build a pluggable program serving requests to anything on the internet it may increased response times by anything between 30-100ms.

Stdin to Stdout

The difference to the client-server solution is subtile when it comes to the details in implementation. protoc-gen-go and other plugins in the Protocol Buffers ecosystem use this approach.

Plugins are again executables that the main program runs. But in contrast to the client-server communication via gRPC the main program and the plugin communicate via the standard OS streams stdin / stdout with each other. In order to standardize the communication, many of the programs use Protocol Buffers.

Dynamic interpretation

The previous solutions have a performance penalty when it comes to transport information. Traefik and other programs which are sensitive to response times pursue a different approach.

They dynamically load, interpret and execute Go code. The folks at Traefik Labs have created Yaegi to do this. This allows for calling into the plugin code by using an interface and a bit of reflection magic of the runtime. Because the code is loaded and interpreted only once the performance penalty is only a the startup. But, it increases the complexity.

Dynamic libraries with symbol resolution

The supported for plugins in the standard library started in Go1.8. Plugins ought to be shared objects (.so) that can build with ELF symbols that can be dynamically loaded at runtime. However, the progress has been fairly limited. Currently plugins are only supported on Linux, FreeBSD, and macOS. There are many issues with sharing modules in the plugin and the main program. Beyond some examples the use of this solution has been fairly limited.

Module Resolution in Large Projects with TypeScript

Sebastian Döll — Tue, 02 Feb 2021 14:30:25 +0000

This post explains how to use custom paths for efficient Module Resolution in large TypeScript projects.

A Primer of Modules

Looking at the State of the Octoverse 2020 you see that TypeScript has surged in popularity. TypeScript adds an unsound type system and powerful compiler to the JavaScript ecosystem.

Modules are not exclusive to TypeScript. They have been introduced with ECMAScript 2015 and TypeScript shares this concept.

Modules contain code that is executed within their own scope, not in the global scope. That means all variables, functions, classes, etc. that are declared in a module are not visible outside of the module unless they are explicitly exported using one of the export mechanisms. To consume the exported variable, function, class, interface, etc. it has to be imported using one of the import mechanisms.

The common mechanism today is the ES module: ECMAScript 2015, or ES6 module using the import/export statements.

An example of a module is a React component that is shared between different pages. Extracting code into modules does not only make it easier to maintain a large code base and test functionality, but also to optimize your code. ES2015 allows to eliminate unused code via tree shaking.

# DefaultLayout.tsx
import React from 'react'

interface DefaultLayoutProps {
  children: React.ReactNode
}

export const DefaultLayout = ({ children }: DefaultLayoutProps): JSX.Element => (
  <div>{children}</div>
)

export default DefaultLayout

This component has a named export of DefaultLayout and a default export.

Importing Modules

A typical folder structure for the React component 👆 in a Next.js looks like this.

.
├── src
│   ├── components
│       └── layout
│           └── DefaultLayout.tsx
│   ├── graphql
│   ├── hocs
│   ├── hooks
│   ├── pages
│   ├── state
│   ├── theme
│   ├── types
│   └── utils

To import this DefaultLayout component in the DefaultLayout.tsx the compiler needs to know where the module is located. Usually this is done by specifying a relative path to the component import DefaultLayout from '../../components/DefaultLayout.

However, the TypeScript compiler can be instructed to use a different path to resolve the location of the module. This can be done via the tsconfig.json file.

{
  "compilerOptions": {
   ...
    "paths": {
      "@components/*": [
        "./src/components/*"
      ],
      "@theme/*": [
        "./src/theme/*"
      ],
      "@utils/*": [
        "./src/utils/*"
      ],
      "@hooks/*": [
        "./src/hooks/*"
      ],
      "@state/*": [
        "./src/state/*"
      ],
      "@pages/*": [
        "./src/pages/*"
      ],
      "@hocs/*": [
        "./src/hocs/*"
      ],
      "@type/*": [
        "./src/types/*"
      ],
    }
  }
}

By adding these custom paths for the module resolution, modules the DefaultLayout component can be imported with import DefaultLayout from '@components/layout/DefaultLayout'.

import React from 'react'
import DefaultLayout from '@components/layout/DefaultLayout

const App = (): JSX.Element => <DefaultLayout />
export default App

⚡️ A great resource for writing React apps with TypeScript are the React TypeScript Cheatsheets

Deploy AWS CloudFormation stacks with GitHub Actions + React Example

Sebastian Döll — Tue, 28 Jul 2020 10:18:33 +0000

You want to deploy your infrastructure with GitHub Actions?

I have published AWS CloudFormation Action for GitHub Actions and walk you through the example of a React app in an article on the AWS Open Source Blog.

You can also use the Create React App Template for AWS Amplify to shortcut the process to connect the app to the AWS Amplify Console with AWS CloudFormation.

👇

npx create-react-app my-app --template amplify-typescript

Go build!