Is this another Kafka console?
In shape, yes: topics, consumer groups, schemas, connectors and ksqlDB are all there, and you can use Alginte for nothing else. In purpose, no. Alginte exists to build, run and observe Kafka Streams applications, and the console pages are the surroundings a stream needs: the topic you read, the group you become, the subjects your changelogs register, the sink you write. If you only need a console, several good ones exist. If you want stateful stream applications without writing code, checked against real records before they run, and the state they have while running, that is what Alginte is for. Start with the Streams builder overview.What if I already have a Kafka console?
Keep it. Alginte runs beside it: connect it with read-only credentials and it writes nothing to the cluster until you deploy a stream. Use Alginte for the streams half, building, running and watching them, and your other console for what it does well. There is no migration, no shared state between the two, and nothing to undo if you stop using one.What do I gain by running my stream application in Alginte?
- Build it visually, with SpEL for the logic, and see the real record shape at every node before deploying: the editor previews your expressions on records from the actual topic and validates against a deployed topology’s behaviour. See Building a stream.
- Deploy in one click, and see what no consumer-group view can show: whether the stream is restoring a store and how far along it is, changelog and standby lag, thread state read against the client state, rebalance history. See Monitoring.
- State handled honestly. Deleting a stream can take its cluster state with it, and redeploying onto old state asks first instead of adopting it silently. See Deploy and operate.
- It stays a standard Kafka Streams application: the same consumer group, the same changelog and repartition topics, the same metrics, nothing proprietary on the cluster. Other tools see it as they see any Streams application.
Does Alginte need write access to my cluster? What does it write?
To browse and to observe, no:DESCRIBE on groups and topics and READ on topics is enough, and
nothing is written. Observing streams you did not deploy needs the same. See
which view you get.
To deploy a stream, yes, the rights any Kafka Streams application needs: it creates its own
internal topics (changelogs, repartitions), joins its consumer group and commits offsets, and
writes to the sink you chose. Nothing else is written, and no internal topic of Alginte’s own is
created on the Community edition. What runs where, and how the console is placed on a network,
is on Production.
Does running my streams inside the console make it heavy?
Alginte is one Spring Boot application, which is what most Java Kafka Streams applications are. A stream deployed in it runs the same Kafka Streams client, with the same threads and the same local RocksDB state, that it would have on its own; the console adds its web server and UI once, not per stream. What changes is where the stream lives: in the console’s process, on the console’s host. Give the instance the memory and disk you would give the stream on its own; the UI’s needs are small beside it, and the stream’s threads run next to the web server without getting in each other’s way on a modern machine. To scale a stream, deploy the same design on several instances; they join one consumer group and split the partitions the standard way. See Scaling out. A headless stream host, an Alginte runtime that runs streams outside the console process and reports back to it, is planned and not yet available.Can I take what I built and run it without Alginte?
You keep the design and the running application. Download exports the whole design as a file that imports back, so your topologies live in your repository, not in the console (save your work). A deployed stream shows itsTopology#describe() as text or a diagram, the same description Kafka Streams prints, so
what runs is readable outside Alginte. What you do not get is a generated code project: Alginte
runs the topology from its definition rather than generating code, which is why the definition
is the durable artefact.