When people first look at distlang, they usually see the portability story first. You write your application once. distlang builds it for the platform you want to run on. That part is easy to explain, and it is an important part of the project. But portability by itself is not enough. The portability problem becomes harder once you add other features to an application like a database, metrics, queues, or AI workloads. Each platform handles these differently, and the application starts to absorb infrastructure concerns that should not belong in business logic.

Helpers in distlang are platform-agnostic libraries that expose useful capabilities to your application without forcing the application itself to carry the full weight of platform APIs, deployment configuration, and secret management. They are part of distlang, not just an extra SDK layered on top. You can find the API Docs here. The goal is simple: let application code ask for a capability, and let distlang handle what is needed to make that capability real in each environment. That matters for storage, but it matters just as much for systems like metrics pipelines, queueing systems, and AI workloads where providers differ in APIs, authentication, latency tradeoffs, and cost controls.

Once you use helpers there is no reason to use vendor specific bindings to the databases which makes using a databases really fast and easy.

import { helpers } from "distlang";

await helpers.ObjectDB.put("notes", "hello", { message: "hi" });

An application imports a helper from distlang, uses it directly in code, and keeps moving. The code stays focused on intent. The distlang toolchain figures out how to make that intent work in local development, in tests, and in deployed environments. For the local environments, we have mocks exposed which will allow you to test your code completely without using the production databases.

When you build a program that imports helpers from distlang, distlang adds the generated helper code needed to support that import. When you run the program locally, distlang can provide a mock path so development and testing do not depend on a live service being available.

Is this secure?

When you deploy the program, distlang can use your authenticated session to obtain the right service token and inject it into the deployment target so the helper can talk to the hosted API. From the point of view of the application, the code stays the same. The build step makes the helper available. The run step gives you a local development story. The deploy step carries the responsibility of wiring live credentials and target-specific runtime configuration.

This lets the application stay small and readable, even when the capability behind the helper is backed by a real hosted service. The secrets added ensures that communication to the helpers API’s happens securely.

What helpers are not

Helpers are not the only way to build applications in distlang. They are not meant to replace every lower-level primitive, and they are not meant to prevent users from building their own storage layers or talking to their own systems directly. In fact, distlang already has a simpler local-first storage helper called InMemDB, which is useful when you want a very lightweight primitive for development or provider-backed runtime bindings. That is a different layer than hosted helpers like ObjectDB.

Helpers are also not an attempt to hide all system design decisions behind a magical interface. They do not remove the need to think about application boundaries or data models. What they do remove is a large amount of repetitive wiring that would otherwise leak into every application.

The power of layering and what comes next

The build step in distlang can generate code and the deploy step can wire in the runtime configuration needed for that code to work. ObjectDB is one example of a helper that can be added at build time, but it is only the beginning. The same layering can support helpers for metrics, queues, and AI workloads where the application wants a simple capability while distlang handles provider integration, authentication, and runtime wiring. That is the direction we are exploring next, and it is one of the most interesting parts of what helpers can become.