Skip to main content
The playground is the product with a bundled broker: the same image, the same Streams builder, the same deploy gate. That makes it a workbench, not a demo. A team designs a stream there, proves it against records, and only then puts it on the shared cluster, through a file. This page walks that path once, end to end, and says what changes at the border.
Two Alginte instances are involved: the playground’s, on localhost:8888, and the one you run against your cluster (Quick Start). Nothing moves between them by itself. The design travels as the JSON file you download from one and upload to the other.

​
1. Start in the playground

The stack is yours alone: a single-node Kafka, a Schema Registry and Alginte, bound to your machine, with no volumes. Whatever you deploy here can be thrown away with docker compose down. It comes seeded with topics, real Avro records and a running topology, so the first thing you see is a canvas with numbers on it (what is inside).

​
2. Bring your data’s shape, not your data

A stream is designed against the shape of its input, and the shape lives in two places: the topic and the Schema Registry. Recreate both in the playground:
  • The topic, with the name it will have on the real cluster. Create it on the Topics screen; the partition count does not have to match yet.
  • The subject, when the records are Avro, JSON Schema or Protobuf: register the same schema under the same subject name on the Schema Registry screen. The builder’s completions, the sample preview and the deployed serde all read it from there.
  • A small sample that looks like the real records, produced from the Messages screen against that subject. What it needs is variety, not volume: the ordinary record, and the ones that break things, a null where a field is optional, an empty list, a value on the boundary of your predicate. The preview evaluates your expressions against one real record at a time.
All three are gone at the next docker compose down. To keep them, put the schema and the sample in the two folders beside the compose file, which are registered and produced at every up (bring your schemas and your data). Keep the names identical to the target’s. The design carries topic names and subject names, and the deploy gate on the target refuses a source topic that does not exist there, by name.

​
3. Design, and prove it as you go

Build the topology on the canvas (Building a stream): the source bound to your topic, the operators, the sink. Every expression you write is evaluated against a record from the topic while you type, and the shape it produces is carried to the next node, so what you see at each step is what the deployed operator will do to that record. The gate on Submit checks the rest, co-partitioning at joins, the serde at every sink, a windowed key that cannot be written as it is, and names the node and the fix. Deploy it here. Produce records and watch the sink fill; open the State tab to see the stores, the threads and the lag. A stream that runs wrong in the playground is cheap: fix the design and submit again. A stream that runs right here runs the same Kafka Streams client on the target.

​
4. Download the design

In the wizard header, Download writes the whole design to a file: the configuration, every node with its expressions and serdes, the edges and the canvas layout, stamped with the format version (save your work). The file is named after the application.id. Put it in your repository: it is the durable artefact, and the thing a reviewer reads. What the file does not carry: the records, the topic itself, the subject’s schema, and the stream’s state. Those are the cluster’s, on both sides of the border.

​
5. Upload on the console that runs against your cluster

On the Alginte instance that is connected to the real cluster, open the Streams builder and Upload the file. The wizard opens with the design loaded and the same validation running. Before Submit, check three things on Step 1 and the canvas:
  1. application.id: it names the consumer group and prefixes the internal topics on the real cluster. If a stream under that id has run there before, Alginte says so before deploying and asks whether to continue on its state or start fresh (deploy and operate).
  2. The cluster-bound properties the file may carry, bootstrap.servers, the registry URL, the security settings: the upload leaves them out and says which, so the design brings its logic and not the cluster it was written on, and this console’s own connection applies. Set them on Stream Properties only if this stream needs values of its own.
  3. The topics and subjects, by name, on the real cluster. The gate refuses a missing source topic, and a source whose subject is not on this registry, naming the node, so register the subject first if the target registry does not have it yet.
Then Submit. The deploy is the same gate and the same client; the difference is the cluster it joins.

​
What is different at the border

  • Rights. The playground console is a super-user on its own broker. On the real cluster the console’s principal needs the deploy posture, the rights any Kafka Streams application needs (production).
  • Partitions and parallelism. The playground’s topics have the partition counts you gave them, not the real ones, so a join that is co-partitioned here may not be there, and the other way round. The gate checks co-partitioning at joins on the target, against the real counts.
  • Volume. A design proven on a small sample is proven for its logic, not for its throughput. Watch the State tab and the per-node numbers on the target for the first hour.
  • Durability. On the Community edition a deployment is ephemeral on both sides: a restarted console comes up with no streams, and the design file is the recovery path (restarts and the edition behaviour). The state on the cluster survives; upload and submit again and processing resumes.