The emphasis is on maximum ease of use. The bottom line is this: you write the API as a regular TypeScript class with some restrictions, then the interface is automatically built from the class, which will be used by the client application. Some service information is also generated. All that remains is to configure the connectors (HTTP and WebSocket are available). Validation, connection storage, etc. are handled by TypedAPI. There is support for events.

There are two simple demo applications: Hello, world! and Demo chat.


TypedAPI consists of several libraries that are connected depending on the type of use.

  • typedapi-core: core, connected by client and server
  • typedapi-server: server core, connects to the server, includes the functionality of the HTTP server
  • typedapi-client: client core, connects on the client
  • typedapi-server-ws – WebSocket server
  • typedapi-client-browser-http – HTTP client
  • typedapi-client-browser-ws – WebSocket client
  • typedapi-parser – Parser for class API and interface creation. Connects on the server with the –dev flag
  • typedapi-redis-signaling – for proxying events from microservices to the input API

An example if we want to use a WebSocket connection:

For HTTP connection:

API class requirements

  • All methods must return a Promise
  • There are restrictions on the data type that methods can accept and return (see below)
  • The class can contain child properties-objects, built according to the same rules

Additionally, the class can contain properties of type Event and ParametricEvent to implement events, and there are predefined injections for authorization and storage of basic information about the user (see below).

An example of a class for “Hello, world!”:

Data type restrictions

Methods can return / accept the following data types:

  • Scalar: number, string, boolean, Date, undefined, null
  • Array, Tuple, Enum, Union. May contain only the types described here.
  • Structure objects without methods
  • Indexed objects of type {[key: string | number]: SomeOtherType}

Reception / transmission of any, unknown is prohibited.

Generating the interface

The interface is generated by using the typedapi-parse command from the typedapi-parser package:


  • sourceFilename: The path to the file where your API is stored
  • sourceObjectName: The name of the class in this file
  • outFilename: Path to the file in which the interface for the client will be written
  • reflectionOutFileName: The path to the file that will store reflections for all methods and data. It is used on the server for data validation.

Create a connection

Once you have configured the API and generated the interfaces, you can configure the connection. An example of how it might look for WebSocket:



The HTTP connection is configured in a similar way, you can see it in the documentation.


TypedAPI supports events. With a WebSocket connection, notification occurs in the usual way, by sending data through the socket. HTTP polling is used for HTTP connections.

An example of creating an event on the server:

Client processing:

Parametric events

Parametric events are events in which a subscription can have specific parameters that determine whether to notify the user about a particular event. More details about parametric events can be found in the documentation.


In order to implement authorization in your API, you need to:

  • Implement SessionProviderInterface and pass it to the service constructor. By default, the MemorySessionProvider is used, which will be reset on every server reboot.
  • Implement methods that return AuthDataResponse. This is a special method response that is handled differently than the other responses.

The AuthDataResponse interface looks like this:

example of API implementation with authorization:

Also, in addition to apiUserId, you can get other data about the user, see the documentation for more details.


To split the API into microservices, the following idea is used: on each microservice, an API instance is raised, and with the help for each instance, it is established which service will be responsible for processing certain methods. There are the following tools for this:

  • HttpProxyClient – This object proxies method calls from the input API to the internal service.
  • HttpTrustServer – This object accepts a call from HttpProxyClient and invokes the requested method
  • RedisPublisher – Attaches to an API, listens for events, and routes them to Redis. Used in internal services.
  • RedisSubscriber – Listens for events from Redis, and runs them on the input API

The architecture might look something like this:

Code examples can be found in the documentation.