In Depth: Speakeasy vs liblab
Nolan Sullivan
July 5, 2024
This analysis compares Speakeasy & liblab in terms of SDK generation, OpenAPI integration, language support, features, platform support, enterprise support, and pricing. We'll also provide a technical walkthrough of generating SDKs using both services, and compare the generated TypeScript SDKs.
In Short: How Do Speakeasy and liblab Differ?
-
OpenAPI Integration: Speakeasy is built for OpenAPI, supporting advanced features of OpenAPI 3.0 and 3.1, while testing and implementing upcoming OpenAPI features like OpenAPI Overlays (opens in a new tab) and Workflows (opens in a new tab). liblab uses OpenAPI as a starting point, but has not yet implemented advanced OpenAPI features like overlays or workflows, instead depending on its own configuration system. This can lead to a divergence between the OpenAPI document and the generated SDK, and may require additional configuration after spec changes.
-
Velocity and Language Support: liblab was founded in January 2022 (opens in a new tab) and gradually expanded its language support and features to support seven languages. In comparison, Speakeasy was founded in May 2022, found market traction in early 2023, and released support for ten languages within 12 months. Speakeasy meets the diverse needs of users, while supporting their existing stacks.
-
SDK Generator Maturity: Speakeasy creates SDKs that are idiomatic to each target language, type safe during development and production, human-readable, and fault-tolerant. Our comparison found some room for improvement in liblab' type safety, fault tolerance and SDK project structure. Both products are under active development, and improvement should be expected.
Comparing Speakeasy and liblab
We'll start by comparing the two services in terms of their SDK generation targets, features, platform support, enterprise support, and pricing.
SDK Generation Targets
As your user base grows, the diversity of their technical requirements will expand beyond the proficiencies of your team. At Speakeasy, we understand the importance of enabling users to onboard with our clients without making major changes to their tech stacks. Our solution is to offer support for a wide range of SDK generation targets.
The table below highlights the current SDK language support offered by Speakeasy and liblab as of June 2024. Please note that these lists are subject to change, so always refer to the official documentation for the most up-to-date information.
Language | Speakeasy | liblab |
---|---|---|
Go | ✅ | ✅ |
Python | ✅ | ✅ |
Typescript | ✅ | ✅ |
Java | ✅ | ✅ |
C# | ✅ | ✅ |
PHP | ✅ | ✅ |
Swift | ✅ | ✅ |
Kotlin | ⚠ Java is Kotlin-compatible | ⚠ Java is Kotlin-compatible |
Terraform provider | ✅ | ✅ |
Ruby | ✅ | ❌ |
Unity | ✅ | ❌ |
Postman Collection | ✅ | ❌ |
Everyone has that one odd language that is critical to their business. In our first year, we've made a dent, but we've got further to go. See a language that you require that we don't support? Let us know (opens in a new tab).
SDK Features
This table shows the current feature support for Speakeasy and liblab as of June 2024. Refer to the official documentation for the most recent updates.
Feature | Speakeasy | liblab |
---|---|---|
Union types | ✅ | ✅ |
Discriminated union types | ✅ | ✅ |
Server-sent events | ✅ | ❌ |
Retries | ✅ | ⚠ Global Retries Only |
Pagination | ✅ | ❌ |
Async support | ✅ | ✅ |
Streaming uploads | ✅ | ❌ |
OAuth 2.0 | ✅ | ❌ |
Custom SDK Naming | ✅ | ✅ |
Customize SDK Structure | ✅ | ❌ |
Custom dependency injection | ✅ | ✅ |
Speakeasy creates SDKs that handle advanced authentication. For example, Speakeasy can generate SDKs that handle OAuth 2.0 with client credentials - handling the token lifecycle, retries, and error handling for you.
liblab leaves some of these features to be implemented by the user. For example, liblab's configuration allows for global retries on all operations, but only recently released support for custom retries requiring custom implementation per SDK.
liblab also lacks support for pagination, server-sent events, and streaming uploads.
Platform Features
Speakeasy is designed to be used locally, with a dependency-free CLI that allows for local experimentation and iteration. This makes it easier to test and iterate on your SDKs, and allows for custom CI/CD workflows.
For local use, liblab provides an NPM package with a dependency tree of 749 modules. Installing and updating the liblab CLI is slower than Speakeasy's single binary, the CLI is less feature-rich, and it depends on Node.js and NPM.
Feature | Speakeasy | liblab |
---|---|---|
GitHub CI/CD | ✅ | ✅ |
CLI | ✅ | ✅ |
Web Interface | ✅ | ✅ |
OpenAPI overlays | ✅ | ❌ |
Package Publishing | ✅ | ✅ |
Product Documentation | ✅ | ✅ |
OpenAPI Linting | ✅ | ✅ |
Change Detection | ✅ | ❌ |
Enterprise Support
Both Speakeasy and liblab offer support for Enterprise customers. This includes features like concierge onboarding, private Slack channels, and enterprise SLAs.
Feature | Speakeasy | liblab |
---|---|---|
Concierge onboarding | ✅ | ✅ |
Private Slack channel | ✅ | ✅ |
Enterprise SLAs | ✅ | ✅ |
User issues triage | ✅ | ✅ |
SOC 2 compliance | ❌ | ✅ |
Pricing
Speakeasy offers a free tier, with paid plans starting at $250 per month.
liblab's free tier is limited to open-source projects, with paid plans starting at $120 per month.
Both services offer custom enterprise plans.
Plan | Speakeasy | liblab |
---|---|---|
Free | 1 free Published SDK | Open-source projects only |
Startup/Starter | 1 free + $250/mo/SDK; max 50 endpoints | $120/mo |
Enterprise/Advanced | Custom | Custom |
Speakeasy vs. liblab Technical Walkthrough
To start our technical comparison, let's create an SDK using Speakeasy and liblab. We'll create an OpenAPI document for a fictional bookstore API, that covers a broad range of OpenAPI functionality. You can find the complete OpenAPI document in the example repository (opens in a new tab), but let's take a look at what's included.
Our bookstore OpenAPI document is compliant with OpenAPI 3.1, which is supported by both Speakeasy and liblab. We define a basic info section and add a single development server.
Here we define two tags to organize our operations with: Books
and Orders
.
We define one global authentication method, apiKey
.
Let's take a look at the operations we'll need an SDK for, starting with getAllBooks
.
This operation takes no input.
What makes this operation interesting is that it returns an array of objects of three types: ProgrammingBook
, FantasyBook
, and SciFiBook
. Each object's type is determined by the book's category.
This example allows us to test how our SDK generators handle discriminated unions in OpenAPI.
Next up, we have an operation that adds a book to the database, called addBook
.
This operation takes one object of type ProgrammingBook
, FantasyBook
, or SciFiBook
as input.
Our next book-related operation, updateBookCoverById
, takes a book ID as a path variable, and an image as a binary payload.
We include this operation to test how our SDK generators handle binary payloads.
Our final book-related operation, getBookById
, takes a book ID as a path variable, and returns one of our book objects.
Next up, we have an operation that returns a list of all orders in the database, called getAllOrders
.
This operation returns an array of Order
objects, so that we can test an array of nested objects.
Our next order-related operation, createOrder
, takes an object of type NewOrder
as input, and returns an object of type Order
.
We include this one to test how our SDK generators help users avoid common mistakes, like passing the wrong type to an operation.
Finally, we have an operation that returns a stream of order events, called getOrderStream
.
We include this operation to test how our SDK generators handle server-sent events.
The remainder of the OpenAPI document defines the components used in the operations above.
Our bookstore OpenAPI document is compliant with OpenAPI 3.1, which is supported by both Speakeasy and liblab. We define a basic info section and add a single development server.
Here we define two tags to organize our operations with: Books
and Orders
.
We define one global authentication method, apiKey
.
Let's take a look at the operations we'll need an SDK for, starting with getAllBooks
.
This operation takes no input.
What makes this operation interesting is that it returns an array of objects of three types: ProgrammingBook
, FantasyBook
, and SciFiBook
. Each object's type is determined by the book's category.
This example allows us to test how our SDK generators handle discriminated unions in OpenAPI.
Next up, we have an operation that adds a book to the database, called addBook
.
This operation takes one object of type ProgrammingBook
, FantasyBook
, or SciFiBook
as input.
Our next book-related operation, updateBookCoverById
, takes a book ID as a path variable, and an image as a binary payload.
We include this operation to test how our SDK generators handle binary payloads.
Our final book-related operation, getBookById
, takes a book ID as a path variable, and returns one of our book objects.
Next up, we have an operation that returns a list of all orders in the database, called getAllOrders
.
This operation returns an array of Order
objects, so that we can test an array of nested objects.
Our next order-related operation, createOrder
, takes an object of type NewOrder
as input, and returns an object of type Order
.
We include this one to test how our SDK generators help users avoid common mistakes, like passing the wrong type to an operation.
Finally, we have an operation that returns a stream of order events, called getOrderStream
.
We include this operation to test how our SDK generators handle server-sent events.
The remainder of the OpenAPI document defines the components used in the operations above.
Installing Speakeasy CLI
Speakeasy CLI is distributed as a single binary, which you can install directly from GitHub (opens in a new tab), or by using Homebrew on macOS:
Installing liblab CLI
liblab CLI is distributed as an NPM package, which you can install using the following command:
Linting OpenAPI Documents
Before generating an SDK, it's a good idea to lint your OpenAPI document. This ensures that your document is valid and that your SDK will be generated correctly.
Speakeasy's CLI includes a linter that checks your OpenAPI document for errors and warnings, and provides helpful hints on how to improve your document.
To lint your OpenAPI document, run the following command in the terminal:
To validate your OpenAPI spec using liblab, run the following commands in the terminal:
Generating SDKs: Speakeasy vs. liblab
Let's generate an SDK each using Speakeasy and liblab.
Creating an SDK using Speakeasy CLI
To generate an SDK, locate your openapi.yaml file and run the following in the terminal:
Speakeasy lints the OpenAPI document, then creates a new folder with the generated SDK.
This happens locally, and you have immediate access to start testing your SDK. We'll explore the SDK shortly.
Generating an SDK using liblab CLI
To generate an SDK using liblab, run the following command in the terminal:
liblab creates a new folder output/typescript
with the generated SDK.
Setting Up a Mock Server
We used Stoplight Prism (opens in a new tab) to generate a mock server to test our SDKs:
This command starts a mock server at http://localhost:4010
.
TypeScript SDK comparison
Now that we have two TypeScript SDKs generated from a single OpenAPI document, let's see how they differ.
SDK Structure Overview
Before we dive into the detail, let's get an overall view of the default project structure for each SDK.
Speakeasy automatically generates detailed documentation with examples for each operation and component, while liblab generates an examples
folder with a single example.
liblab generates a test
folder, while Speakeasy does not. We'll take a closer look at this shortly.
In the comparison below, comparing the folder structure might seem superficial at first, but keep in mind that SDK users get the same kind of high-level glance as their first impression of your SDK. Some of this may be a matter of opinion, but at Speakeasy we aim to generate SDKs that are as organized as SDKs coded by hand.
Speakeasy SDK Structure
Speakeasy generates separate folders for models and operations, both in the documentation and in the source folder. This indicates a clear separation of concerns.
We also see separate files for each component and operation, indicating modularity and separation of concerns.
liblab SDK Structure
liblab generates an SDK that at a glance looks less organized, considering the greater number of configuration files at the root of the project, the lack of a docs
folder, and the way the src
folder is structured by OpenAPI tags instead of models and operations.
SDK Code Comparison
With the bird's-eye view out of the way, let's take a closer look at the code.
Runtime Type Checking
Speakeasy creates SDKs that are type safe from development to production. As our CEO recently wrote, Type Safe is better than Type Faith (opens in a new tab).
The SDK created by Speakeasy uses Zod (opens in a new tab) to validate data at runtime. Data sent to the server and data received from the server are validated against Zod definitions in the client.
This provides safer runtime code execution and helps developers who use your SDK to provide early feedback about data entered by their end users. Furthermore, trusting data validation on the client side allows developers more confidence to build optimistic UIs (opens in a new tab) that update as soon as an end user enters data, greatly improving end users' perception of your API's speed.
Let's see how Speakeasy's runtime type checking works in an example.
Consider the following Book
component from our OpenAPI document:
Book: type: object required: - title - description - price - category - author properties: id: $ref: "#/components/schemas/ProductId" title: type: string example: Clean Code description: type: string example: A Handbook of Agile Software Craftsmanship price: type: integer description: Price in USD cents example: 2999 category: type: string enum: - Sci-fi - Fantasy - Programming example: Programming
The highlighted price
field above has type integer
.
The price
field in the Book
object in our test code is set to 29.99
, which is a floating-point number. This will cause a validation error before the data is sent to the server, as the price
field is expected to be an integer.
Handling Zod validation errors (opens in a new tab) is straightforward, and allows developers to provide meaningful feedback to their end users early in the process.
The same book object in code using the SDK generated by liblab will only be validated on the server. This means that the error will only be caught from the client's perspective after the data is sent to the server, and the server responds with an error message.
If the server is not set up to validate the price
field, the error will not be caught at all, leading to unexpected behavior in your developer-users' applications.
As a result, developers using the SDK generated by liblab may need to write additional client-side validation code to catch these errors before they are sent to the server.
Components Compared
Speakeasy creates SDKs that contain rich type information for each component in your OpenAPI document. This includes clear definitions of enums, discriminated unions, and other complex types, augmented with runtime validation using Zod.
Let's compare the Order
component from our OpenAPI document in the SDKs generated by Speakeasy and liblab.
Here's the Order
component as generated by liblab:
Note how the products
field is defined as an array of FantasyBook
, ProgrammingBook
, or SciFiBook
. This is a union type, but the SDK generated by liblab does not provide any runtime validation for this field, nor does it give any indication that this is a discriminated union.
Contrast this with the Order
component as created by Speakeasy, which exports a useful Products
type that is a discriminated union of FantasyBook
, ProgrammingBook
, and SciFiBook
, along with a Status
enum for use elsewhere in your code.
Verbose runtime validation is marked as @internal
in the generated code, clearly indicating that it is not intended for direct use by developers, but rather for internal use by the SDK.
Here's the Order
component created by Speakeasy:
OAuth Client Credentials Handling
Only Speakeasy's SDKs handle OAuth 2.0 with client credentials, including managing the token lifecycle, retries, and error handling without any additional code.
Our bookstore API requires an OAuth 2.0 token with client credentials to access the API. Let's see how the SDKs handle this.
Consider the following OAuth 2.0 configuration from our OpenAPI document:
Speakeasy's generated SDK takes a clientID
and clientSecret
when instantiating the SDK. The SDK also includes ClientCredentialsHook
class that implements BeforeRequestHook
to check whether the token is expired and refresh it if necessary. The hook also checks whether the client has the necessary scopes to access the endpoint, and handles authentication errors.
The SDK generated by liblab does not support OAuth 2.0 client credentials at all.
Server-Sent Events (SSE) and Streaming Responses
Our bookstore API includes an operation that streams orders to the client using Server-Sent Events (SSE).
paths: /orderstream: get: summary: Get a stream of orders operationId: getOrderStream description: Returns a stream of orders tags: - Orders security: - apiKey: [] responses: '200': description: A stream of orders content: text/event-stream: schema: $ref: '#/components/schemas/OrderStreamMessage'
Let's see how the SDKs handle this.
Speakeasy generates types and methods for handling SSE without any customization. Here's an example of how to use the SDK to listen for new orders:
(The example above does not run against a local Prism server, but you can test it against Stoplight's hosted Prism (opens in a new tab) server.)
liblab does not generate SSE handling code. Developers using the SDK generated by liblab will need to write additional code to handle SSE.
Streaming Uploads
Speakeasy supports streaming uploads without any custom configuration. OpenAPI operations with multipart/form-data
content types are automatically handled as streaming uploads.
The following example illustrates how to use an SDK created by Speakeasy to upload a large file:
OpenAPI Extensions and Overlays vs. liblab Config
Speakeasy embraces OpenAPI as the source of truth for generating SDKs. This means that Speakeasy does not require any additional configuration files to generate SDKs, apart from minimal configuration in the gen.yaml
file.
Any configuration related to individual operations or components is done in the OpenAPI document itself, using OpenAPI extensions. Speakeasy provides a list of supported OpenAPI extensions in its documentation.
If editing your OpenAPI document is not an option, Speakeasy also supports the OpenAPI Overlays specification, which allows you to add or override parts of an OpenAPI document without modifying the original document.
This step can form part of your CI/CD pipeline, ensuring that your SDKs are always up-to-date with your API, even if your OpenAPI document is generated from code.
Speakeasy's CLI can also generate OpenAPI overlays for you, based on the differences between two OpenAPI documents.
Instead of using OpenAPI extensions, liblab uses a configuration file (opens in a new tab) to customize SDKs. This configuration overrides many of the aspects Speakeasy allows you to configure in the OpenAPI document itself, or using overlays.
Linting and Change Detection
Speakeasy's CLI includes a detailed and accurate linter that checks your OpenAPI document and provides feedback. This is especially useful during development, but can also catch errors in your CI/CD pipeline.
Speakeasy also keeps track of changes in your OpenAPI document, and versions the SDKs it creates based on changes.
Building for the Browser
Both Speakeasy and liblab generate SDKs that can be used in the browser. To use the SDKs in the browser, you need to bundle your application using a tool like Webpack, Rollup, or esbuild.
Speakeasy creates SDKs that are tree-shakeable, meaning that you can include only the parts of the SDK that you need in your application. This can help reduce the size of your application bundle.
Because Speakeasy SDKs include runtime type checking, the Zod library is included in the bundle. However, if you use Zod in other parts of your application, you can share the Zod instance between the SDK and your application to reduce the bundle size.
Here's an example of how to bundle an application that uses the Speakeasy SDK for the browser without Zod using esbuild:
Speakeasy Compared to Open Source Generators
If you are interested in seeing how Speakeasy stacks up against other SDK generation tools, check out our post.