Improve get started experience by providing default topic

[menski]

Currently the user has to create a topic manually after starting the broker. It could improve the get starting experience if on startup a default topic is created.

Pros:

• distribution usable out of the box without setup
• better get started experience

Cons:

• magical default topic which cannot be deleted
• if the user does not want to use the topic it will waste additional resources (disk space, memory, network traffic)

[ThorbenLindhauer]

Maybe we should also discuss the question why users should have to deal with topics at all at this point (i.e. why is more than one topic useful?).

[menski]

We discussed that issue in the team meeting and decided to not reintroduce the default-topic with the following reasons:

• only a single command is required to create a topic
• it is common for systems like Zeebe to have an initial setup step to create the topics required for the use case of the user
• users should be aware that topics exists and what their use case/value is
• we will improve the documentation for topics to explain the logical reason of topics Explain topic use case/values in documentation #548
• in a production use case of Zeebe there is no value in a default-topic and we currently focus on getting Zeebe production ready

[berndruecker]

Hi @menski - sorry - I didn't get notification by mail and missed that one. What's the best way to discuss this if I still do not agree?

only a single command is required to create a topic

It is not about the complexity of doing it, but you have to know it!

it is common for systems like Zeebe to have an initial setup step to create the topics required for the use case of the user

There is no system like Zeebe - so that's not a good argument :-) And if you refer to systems like Kafka I think we should not copy their get started experience - it is aweful!

users should be aware that topics exists and what their use case/value is

I think you can go a long way on the learning curve without this knowledge. So all I am saying is that we should not slam this into the face of a user in the very first step.

we will improve the documentation for topics to explain the logical reason of topics #548

If only users would read documentations.... ;-)

in a production use case of Zeebe there is no value in a default-topic and we currently focus on getting Zeebe production ready

Does it harm if it is always there? If this is the major concern I think it would be more logical to introduce a configuration flag to disable the default topic - as this can be done by users which already learned about topics and decided not to use a default one.

My two cents

[menski]

Hi @berndruecker,

thanks for you feedback.

What's the best way to discuss this if I still do not agree?

We can continue to have the discussion in this ticket, create a forum thread or do it on slack. Whatever you prefer.

It is not about the complexity of doing it, but you have to know it!

Yes that is right and that is why we want to provide a get started guide which teaches you that #526

There is no system like Zeebe - so that's not a good argument :-) And if you refer to systems like Kafka I think we should not copy their get started experience - it is aweful!

I think there exists systems which are similar to Zeebe in how to setup, operate and use them. It's not about copying get started experiences but focusing on production use of the system.

I think you can go a long way on the learning curve without this knowledge. So all I am saying is that we should not slam this into the face of a user in the very first step.

I'm not sure how the first step of creating a topic is to complicated for a user and would block him from using Zeebe. That would be the same as saying a user has a hard time to use a DBMS because a database has to be created as first step.

If only users would read documentations.... ;-)

Personally I think if the documentation is good users like to read documentation. Not saying that the Zeebe documentation already reached this level of usefulness.

Does it harm if it is always there?

Not sure about harm but as Zeebe does not provide a API to get rid of it I would say that it at least could be inconvenient to have resources acquired for a topic you don't want to use in production.

If this is the major concern I think it would be more logical to introduce a configuration flag to disable the default topic - as this can be done by users which already learned about topics and decided not to use a default one.

I think a configuration flag could be an option to provide a default topic but then again it is the question what should be the default value. Would the default to create a topic on startup the production users are required to always adjust the configuration before using the distribution and if they forget that they have a topic they cannot get rid of, which I don't like personally. If the default would be to not create a default topic the getting started experience would be to adjust the configuration before starting, then there is not much difference than to just run a single command.

In conclusion we decided to not provide a default topic and rather help the user to understand what topics are and how to get started without needing a default topic.

Cheers,
Sebastian

[berndruecker]

In short I do believe that users should not be forced to understand concepts as long as they do not yet need it. This makes it much easier to learn step-by-step and get going without annoyance. You learn just enough for one step at a time.

And I believe that there are different kinds of people out there. A reasonable big group of them will learn by playing around and probably following examples (instead of reading the docs). Not saying, that all people are like this, a lot of people will read the docs first. But the "players" will just grab an example from GitHub and get going. And then it is a huge difference:

• the readme just says: Grab Zeebe, unzip and start it (for which you do not even need detailed instructions) - or even easier: docker run zeebe. Now you can run the example code right away.
• the readme has to explain that you have to create a topic (eh, what's that? Here you have to read about it. We know that it is not relevant for you now, but you have to know about it when you scale out in a year or a couple of years from now, given that you like our technology and continue using it. Ah - and making the assumption you really want to scale out. So this is why it is good to read that now.)

OK, ok, I am exaggerating bit time :-) But I hope you understand what I mean. Probably we can also discuss it later F2F.

So my vote is to have a configuration property “create-default-topic” and enable that by default in the distro. You can overwrite properties by environment variables so that makes it easy to change the flag. (We could even ship different start scripts if we want to.) And I think an unused default-topic should not harm anything anyway - so there is no real need to change it.

And: My vote is also to adjust the Client API in a way, that it can also work without specifying a topic name (you can, but this is optional). If no topic is specified the default-topic shall be used.

PS: One great thing using the Spring stuff for Kafka is that they auto-create the topics for you. Spring also auto-creates all queues for Rabbit. And most database tools auto-create databases and tables for you. "Don't make me think" - even if you don't use these defaults in production often. And I think we should not limit this get-started experience to Spring users, but make it available for everybody.

[menski]

Hi @berndruecker,

thanks again for your input. I will reopen this issue as I see your point, but we will not work on this topic at the moment.

Cheers,
Sebastian

[berndruecker]

Great - thanks! I am happy if we have it in the backlog and I agree that it is not the most urgent matter!

[menski]

With the upcoming Zeebe 0.10.0 release the default topic will be back. The user will also have to option to specify multiple topics to bootstrap in the broker config. Will be implement with #835 .