Stateless Service

Question

I am currently working on a player design. Without going into details I have two main layers 1. Playback services 2. User Interface. Playback services consist mainly of Player service and Browser Service. They communicate over REST API. User Interface subscribes to various services. I want to keep the services as stateless as possible.

I am a bit confused about how to keep the services stateless. Regarding browser it is straightforward. I get a path to navigate, I retrieve the results and publish them and the browser service is stateless again.

However, I don't understand how can I make the player stateless! Lets take the concrete use-cases: Various operations like play, resume, pause etc. can be acted upon only if the player has a certain state. For example, we can't start the playback if there is no track loaded earlier. Similarly, stop makes sense if we are already playing.

Is it the responsibility of the clients to look for the states as they are subscribed to the player and if the player is not in the right state then they have to first bring it into the state that a certain operation makes sense?

Answer 1

One point about the term 'stateless' that may help your understanding is that no useful services are 'stateless' in the sense of having or operating on no state. It's all about where you store the state. Stateless service just means the state isn't stored in the service itself.

For much of what you said, this is simple to achieve in a number of ways. One is you take all the state, and compress it, and encode it (e.g. serialize as json and base64 encode). Then you return that to the client, and the client must pass that into your service (as an argument) on every call.

Then your service maintains no state- the web client (and communications channels) are maintaining it.

A simple variation on this (if the state is large) - is to store the state in a database. It's similar to handing the data back to the web client - but you had back to the web client a 'row id' from the database, and fetch the 'state' from the database on each web service call.

For audio-playback, the state consists of 'where you are in the audio' and other such things. THOSE are small enough that you can use the convert-to-json and base-64-encode approach (especially if you add compression). But the actual 'audio files' are relatively big. So you need to cheat a little. Maintain a 'cache' of in memory audio files. You are then slightly cheating - since the in-memory cache of audio is - in a sense - state. but its not essential state (if you killed the process and restarted - it would still work - just more slowly).

Answer 2

As I understand, any operation will be initiated by the client application. So, it becomes mandatory for the client application to ensure that the player is in proper state. This is to keep the client application stateless.