It's unfortunately quite boilerplate-heavy. Would be nicer with associated type defaults but they're unstable :/

But on the whole this makes a lot of sense to me. Some services already effectively use this pattern, this just codifies it.

Yes, unfortunately without that feature it's a bit boilerplate heavy. I considered requiring the Default trait bound to initialize the state and have a default impl. for pre_spawn but requiring the Default bound on some states, makes it unnecessarily complex for states that will always be created without the need of a default.

For me currently this seems like it adds more to the 'framework' which needs to be supported by each individual service, but does not add functionality to the framework which makes creating and managing services easier.

So it has a bit the opposite effect, it puts more burden on the implementation side, which is what we would ideally like to reduce. That's where the benefits come from (1 framework, but many services).

I fully agree.

In the service rewrite I attempted, I implemented an abstraction similar to a framework. Unfortunately, it didn’t align well with our specific service usage so I discarded it.

Rather than adding new functionality, this approach focuses on standardizing common service use cases through abstractions, nothing more.

If you have any proposals to do this better, more than happy to start a discussion.

For me currently this seems like it adds more to the 'framework' which needs to be supported by each individual service

I would only go through with this change if we can have sensible defaults, i.e.

1. services that don't need a public state automatically get () somehow (not sure if this is possible without the associated type defaults that @loewenheim mentioned),
2. default impl of pre_spawn,
3. .start() still returns an Addr as before. Offer an additional start_observable() if the client of the service actually needs to observe it.

Passing the shutdown handle into spawn_handler might be a good idea independent of the other changes, also for testability.

For me currently this seems like it adds more to the 'framework' which needs to be supported by each individual service

I would only go through with this change if we can have sensible defaults, i.e.

1. services that don't need a public state automatically get () somehow (not sure if this is possible without the associated type defaults that @loewenheim mentioned),
2. default impl of pre_spawn,
3. .start() still returns an Addr as before. Offer an additional start_observable() if the client of the service actually needs to observe it.

Passing the shutdown handle into spawn_handler might be a good idea independent of the other changes, also for testability.

I can make all of such changes but the Default one is not ergonomic, since it forces states to have defaults even when they are not needed.

Rather than adding new functionality, this approach focuses on standardizing common service use cases through abstractions, nothing more.

I don't see the upside of this at the moment. More abstractions should also take over logic/complexity of the individual services. For example, instead of passing down a shutdown handle (which could also just be another argument to the constructor), could the framework manage graceful shutdowns including dependencies.

Rather than adding new functionality, this approach focuses on standardizing common service use cases through abstractions, nothing more.

I don't see the upside of this at the moment. More abstractions should also take over logic/complexity of the individual services. For example, instead of passing down a shutdown handle (which could also just be another argument to the constructor), could the framework manage graceful shutdowns including dependencies.

I explored this. The problem, which I might need help with is that we need to have all the code in a top-level select in the loop which polls from multiple futures and you can't fuse selects (from what I saw). Another mechanism would be to handle the shutdown by spawning a separate task for each service which is somehow bound to the joinhandle of the main task and kills it (if it's possible).

There is always the option of not doing something if the alternative does not achieve what was hoped.

There is always the option of not doing something if the alternative does not achieve what was hoped.

Indeed, this is the reason why we are discussing it.