InfluxDB 2.0 Client Libraries by Noah Crowley

Noah Crowley / Developer Advocate
InfluxDB 2.0 Client
Libraries

© 2018 InfluxData. All rights reserved.
A new approach for Clients in InfluxDB 2.0
• In 1.x, the client libraries were community-led efforts

• A function of available resources — not enough engineers!

• Has been a successful effort; supports 17 languages

• Some issues with consistency across libraries

• Function names, batching and buffering of data

• In 2.0, the client libraries are part of the work we’re doing on the
platform as a whole

An API-driven approach
• 2.0 has a consistent and easy to use API across all products

• Open Source, Enterprise, Cloud

• Allows for easy migration of workloads

• Want to give developers an equally consistent and easy to use set
of client libraries

• Consistency of function names (with respect to language
idioms)

• Ease of use: Documentation & examples, always up-to-date

Defining the API: Swagger
• The InfluxDB repo contains an API specification

• Industry-standard format

• Information about endpoints, parameters, security, etc.

• Single source of truth

• Allows the specification to be checked into Git and
versioned alongside the code

• Provides a contract for engineers to follow when developing
against the API

/telegrafs:
get:
tags:
- Telegrafs
parameters:
- $ref: '#/components/parameters/
TraceSpan'
- in: query
name: orgID
description: specifies the organization
of the resource
required: true
schema:
type: string
responses:
'200':
description: a list of telegraf configs
content:
application/json:
schema:
$ref: "#/components/schemas/Telegrafs"
default:
description: unexpected error
content:
application/json:
schema:
$ref: “#/components/schemas/Error"

Developing against the API: Swagger Codegen
• Swagger also gives us the ability to do code generation

• Both client and server are possible

• Tradeoffs between codegen and writing libraries by hand

• Ideally the libraries would be fully autogenerated, minimizing
the amount of work that needs to be done

• Tightly couples the code to the spec, making it difficult to
diverge

• At the very least, can give developers a starting point

• Downsides:

• Beholden to the quality of the code produced by the generator

• Performance & User Experience

• Time spent learning tooling

• Wasn’t something we were interested in for the server

• Codegen for the client libraries:

• For some languages, this is a viable option

• For others, the generated code is better used as a starting
point

Consistent Guidelines for API Libraries
• As we work through the Alpha and move into the Beta, we’re
continuing to refine our guidelines for writing API libraries

• Care about the user experience: function names, etc.

• Factors outside of the Swagger definition:

• How we batch and write points, and deal with backpressure

• Consistency guarantees for read & write

• Dealing with large/streaming queries

• Codegen is recommended, but likely won’t be required

What does the API give us?
• Two types of endpoints in the API

• Traditional CRUD endpoints for managing resources

• Everything in 2.0 can be managed through the API

• Dashboards, Telegraf configs, users & permissions, etc.

• Two GRPC endpoints for write and query

• Allows us to interact with InfluxDB 2.0 in a purely programmatic
fashion, if we want

Building against the API
• For 1.x, the client libraries have been used for:

• Application instrumentation & performance monitoring

• Support for managing InfluxDB using configuration-as-code
tools such as Terraform and Ansible

• Customer-facing applications that use Time Series Data

• Data analysis tools

• Custom Dashboards

• ETL & Reporting tooling

Building against the API
• Expect to see similar efforts with 2.0

• Building libraries in-house allows the community to focus on
building on top of Influx

Building against the API - New Abstractions
• New features in the API allow for new types of applications

• “Documents” is a simple key-value store that is currently being
used for templating within the UI

• Wanted to abstract the Chronograf-specific APIs of 1.x

• Allow developers to write additional data directly to the
database without using another tool

• Can be used for storing metadata for an IoT application,
dashboard customizations, etc.

Key Libraries
• Critical Path: Used by our team to build 2.0

• Go: CLI, Telegraf

• JavaScript: UI

• Being built by the core engineering org, developed as we go

• Some divergence; Go library needs to be made consistent

• Changing as the API and requirements evolve

JavaScript/TypeScript
• Initial version exists at github.com/influxdata/influxdb2-js

• Team decided to make use of autogenerated code

• Which generator?

• Swagger Codegen

• Official, being re-written for OAS 3.0

• Openapi-codegen

• Fork of the OAS 2.0 codegen, support for more
languages, built by Swagger Codegen developers

openapi-codegen
• You can use a Docker container to run the codegen tool:
docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli generate
-i https://raw.githubusercontent.com/influxdata/platform/master/http/cur_swagger.yml
-g go
-o /local/out/go

JVM
• Library for Java, Reactive, Scala, Kotlin

• Built by Bonitoo

• Currently lives at github.com/bonitoo-io/influxdb-client-java

• Hosted in Bonitoo Maven snapshot repo

• Still evolving, ready to be demoed!

• Vaadin Flow demo:

• github.com/rhajek/influx-demo

InfluxDB 2.0 Client Libraries by Noah Crowley

More Related Content

What's hot

Similar to InfluxDB 2.0 Client Libraries by Noah Crowley

More from InfluxData

Recently uploaded

InfluxDB 2.0 Client Libraries by Noah Crowley