Developing with TypeDB in any Programming Language

Alex Walker
Vaticle
Published in
4 min readFeb 16, 2022
TypeDB’s official client drivers (left), and community client drivers (right)

Suppose you want to develop using TypeDB, but your language doesn’t have a TypeDB client library yet. What are the options?

  1. Use a microservice in an already-supported language: One approach is to create a “bridge” service — a Java service, for instance, and expose endpoints for your application to talk to. This works, but introduces a new service, potentially a new language in your ecosystem, and it is slow; all database requests now have to go through an additional communications pipeline in order to be served.
  2. Build a TypeDB Client library: Not only does this avoid all the problems with the microservice approach, it also creates an indispensable tool for the TypeDB community and helps to drive the growth of TypeDB itself!

In this post, we discuss the architecture of a TypeDB Client and possible strategies for building one for you or your organisation’s needs.

What is a TypeDB Client?

A TypeDB client, along with the TypeDB Console and TypeDB Studio, is an interface which we can use to read from and write to a TypeDB database. If we are building an application that uses TypeDB as its database, we would need a TypeDB client at our application layer to handle the database operations.

Application -> TypeDB Client -> Network (gRPC) -> TypeDB Database Server

All TypeDB Clients share a common architecture. Simply put, the main components of a TypeDB client are the client itself, session and transaction. Inside a transaction, we can carry out queries and Concept API calls.

  • A client is responsible for connecting to the TypeDB Server. We then use this connection to manage databases and open sessions.
  • A session holds a connection to a particular database. This connection then allows opening transactions to carry out queries.
  • A transaction performs queries or Concept API calls on the database. TypeDB transactions comply with ACID properties, up to snapshot isolation.
  • A query is a single request. If it’s a Match query, the server will stream responses to the client. For most other query types, the server will simply confirm that the request was successfully processed.
  • The Concept API is effectively a set of specific queries that we can execute cheaply to investigate answers — for example, finding out all the attributes owned by a given entity.

Network Communication with gRPC

gRPC is the network call framework that TypeDB uses. A TypeDB client needs a gRPC client library to communicate with the server. Many languages have gRPC libraries.

Why use gRPC?

Architecturally, gRPC is an alternative to HTTP (say, REST API or websockets). In TypeDB’s client-server architecture, performance is critical, and gRPC fits well with TypeDB’s scaling model. It establishes a long-lasting connection, much like a websocket. Payloads are encoded in the Protocol Buffer format, which is both efficient and strongly typed.

A deeper analysis of the differences between gRPC and REST, and how they affect performance, can be found at https://www.yonego.com/nl/blogs/why-milliseconds-matter/#gref.

The TypeDB Client Spec: TypeDB Protocol

The TypeDB Protocol is the catalogue of all request messages that a TypeDB client can send when talking to a TypeDB server.

Protobuf definition files can be compiled into server-side and client-side libraries using a Protobuf Compiler. In our case, we only need client-side library compilation. Protobuf compilers are available in many languages.

Getting Started

When you’re ready to start building your very own TypeDB Client, check out the “New Client” guide in the docs, and start developing!

The official Vaticle client drivers are all fully open-source and provide a valuable reference point when developing your own client.

TypeDB’s Existing Community Clients

The following is a list of community client drivers built and maintained by the TypeDB community:

Conclusion

A client is considered production-ready once all of its components are completed and well-architected, and it passes the TypeDB behavioural tests.

If you encounter any difficulties along the way, do get in touch with the Vaticle team, preferably on Discord — we’d be delighted to help speed up the development process. This will also enable your project to be added into the TypeDB Open Source Initiative.

Happy coding!

--

--

Alex Walker
Vaticle
Editor for

Software Engineer at Vaticle, building TypeDB clients, websites, visualisers and more