inmake DOCS
Docs / SDK / Connection lifecycle

Connection lifecycle

Sessions, stopping, re-targeting, environments.

src/drop_core.ts

  • DropCore.start(options, session?) — create and register a connection.
  • DropCore.stop(session?) — drop the registered connection.
  • DropCore.get(session?) — resolve the connection (throws via ! if missing).

DropCoreOptions:

field type notes
store string Store id (sid). Sent as the store header.
access_token string Sent as the access-token header.
identity_token string? User-level identity token (minted via secure.access.mintIdentity). Sent as the identity-token header — the server takes the customer, and without an access token the inherited access, from it.
env DropEnv? 'prod' (default) or 'demo'. Picks the default transport's base URL — that's the whole prod ↔ demo switch. Ignored when client is passed (that client carries its own base). Readable back as DropCore.env, with .apiBase / .storageBase for the matching hosts.
target string? Acting store id, distinct from store. For master sessions where the header carries * but each request should act on one concrete sid. Also settable later via DropCore.setTarget(target).
client RequestClient? Override the HTTP transport. Defaults to FetchHttpClient in the browser and the Node DropHttpClient otherwise, both pointed at DropCoreEnv.api(env).

Submodule paths are baked from target at construction. After changing the target, rebuild the DropCoreInstance — don't reuse the old facades.

Environments#

There are two hosted environments — 'prod' and 'demo' (the parallel drop-core-demo project). Switch between them with the env option; it defaults to 'prod', so production callers write nothing:

DropCore.start({ store: 'sid', access_token: 'token' });                  // prod
DropCore.start({ store: 'sid', access_token: 'token', env: 'demo' });     // demo

const drop = initDropCore({ store: 'sid', access_token: 'token', env: 'demo' });

env only chooses the default transport's base URL. Pass client and it is ignored — that client already carries its own base. The session remembers it either way:

const core = DropCore.get();
core.env;           // 'prod' | 'demo'
core.apiBase;       // https://demo-core.inmake.dev/api
core.storageBase;   // …/drop-core-demo.firebasestorage.app  (compose file URLs against this)

DropCoreEnv holds the canonical bases — use it instead of hand-typing hosts:

member value
PROD_API https://core.inmake.dev/api
DEMO_API https://demo-core.inmake.dev/api
PROD_STORAGE / DEMO_STORAGE Public bucket bases. Files store only a bucket-relative storage_path; compose the URL as ${STORAGE}/${storage_path}.
api(env?) / storage(env?) The same two pairs resolved from a DropEnv (undefined → prod).

For anything that isn't one of the two hosted environments (emulator, staging, a signing proxy) supply a client. DropHttpClient.prod(store, token, identity?) / .demo(...) / .for(env, …) are the shorthands; the constructor is (path, store, token, target?, identity?):

import { DropCore, DropHttpClient } from 'drop-core-sdk';

// a fully custom base (e.g. the emulator)
DropCore.start({
  store: 'sid',
  access_token: 'token',
  client: new DropHttpClient('http://localhost:4100/api', 'sid', 'token'),
});

In the browser the default transport is FetchHttpClient (src/repository/drop_fetch_client.ts) — env picks its base just the same, and the Node-only DropHttpClient is never loaded. FetchHttpClient carries the same .prod() / .demo() / .for(env, …) statics for the cases where you construct it yourself (a subclass, a custom base). Its optional sixth constructor argument {timeoutMs} bounds each call (headers and body) and rejects with .code === 'timeout', .status === 504 — a number, or a function of the request URL so a server can time its reads and leave its writes untimed; unset (the default, and what the console uses) means no timeout. Multipart uploads are never timed. Errors thrown by it carry .status, the server's error .code (the envelope's error string) and the parsed error .body, so callers can branch on typed failures (e.g. the analytics reason codes). A typed refusal answered top-level ({error: code, message?, ...detail} — the module, shipping and provider handlers) has no body of its own: .body is then that whole object, so err.body.error and its detail read the same in both shapes.