Share types between client and server

Question

I'm working on a project with a Node.js, Express.js & TypeScript backend (REST API) and a React, Redux & TypeScript frontend.

In the backend I have created some types for example:

models/Product.ts

export type Product = {
    title: string
    description: string
    price: number
}

So the REST API is sending a response like the following:

{
  "data": [
     {"title": "Shoe", "Description": "This is a shoe.", "price": 20},
     {...}
   ] // inside here all the Products[]
}

On the client I want to cast the data to the type Product array. But since the frontend and backend are different code bases and separated, I still want to take the advantage of using types on the frontend. But I want to achieve this without duplicating code. So I don't want to update 2 places when modifying or adding models.

Does someone know what is the best way to share types between client and server?

I was thinking of something like creating an endpoint on the backend which the client can hit, then it writes all the models in a single file for example models.ts on the client. So I think I need to loop through every file inside /models/ on the backend then parsing it in a new file which is written on the client as models.ts. But is this really a good way? Does someone know a better way of achieving this structure?

Answer 1

You can use TypeScript path mapping.

Example from a project I'm the author of:
Backend defined types inside SampleTypes.ts are reused in the client project to avoid duplicating the code.

client/tsconfig.json:

{
  "compilerOptions": {
    "paths": { "@backend/*": ["../server/src/api/*"], },
  }
}

../server/src/api/ -> https://github.com/winwiz1/crisp-react/tree/master/server/src/api

client/....ts:

import { SampleRequest } from "@backend/types/SampleTypes";

Answer 2

You are essentially looking to share code (in your case type definitions) between multiple packages. Yarn has developed workspaces for this purpose, and it does not rely on tsconfig/Typescript as the other answer does.

It's a dive into a rabbit hole, with a bit of work of your Yarn configuration and possibly the use of tools like Lerna. It does make sense however, when you have tightly coupled packages that share types, but perhaps also validation logic.

Answer 3

You can structure your Node.js code in modules where each module's types are in type.ts file.

For example:

src/modules/devices/types.ts

export interface Route {
  timestamp: string
  name: string
  geojsonString: string
}

export type AddRouteBodyParams = Pick<Route, 'name' | 'geojsonString'>

export interface DeleteRouteBodyParams {
  deviceId: string
  timestamp: string
}

export interface EditRouteBodyParams {
  deviceId: string
  timestamp: string
  name: string
  geojsonString: string
}

src/modules/devices/controllerDevice.ts

import type { Request, Response } from 'express'
import type { ParsedQs } from 'qs'

import type { ResponseError, ResponseSuccess } from '../../api-types'

import { editRoute } from './serviceRoutes'
import type { EditRouteBodyParams } from './types'

export const deviceController = {
  editRoute: async (
    req: Request<any, any, EditRouteBodyParams, ParsedQs, Record<string, any>>,
    res: Response<ResponseSuccess | ResponseError>
  ) => {
    const editResponse = await editRoute({ ...req.body })
      if (editResponse instanceof Error) {
        return res.status(500).json({ error: editResponse.message })
      }
      return res.send({ message: `Route with name: ${req.body.name} was updated` })
  },
} as const

Then, you can export all api types into a single file and copy it into front-end project by running npm command:

"scripts": {
    "generate-types": "tsc -p tsconfig-export.json && cp ./dist/export-api-types.d.ts ../client_map_app/src/types"
}

You can check more details here.

Answer 4

Make two same files for shared types on BE and FE. Do an OS Hardlink between them.