1

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?

  • 1
    I am not sure what a playback service is. What does it do? Seems to me you already have a player in the UI, and what you need on the backend is a media data retrieval service. And of course, that could easily be stateless. – John Wu Jun 30 '18 at 9:21
  • Playback service implements the business logic to carry out various operations related to playback, like load track, play, pause, resume etc. UI doesn't have any playback logic, rather it only has the logic related to the UI display and forwarding the user input to the lower layer (playback service or browser). – user2219907 Jun 30 '18 at 13:26
  • That strikes me as a very unusual separation of concerns, but if that is the architecture, the playback service must be stateful. Which is not the end of the world. – John Wu Jun 30 '18 at 19:18
  • Well I guess you could store the state somewhere else, e.g. a signed token held by the client and passed with each request, sort of like a browser cookie. – John Wu Jul 2 '18 at 7:54
  • It should be perfectly fine for the browser to maintain state related to the user session. Keeping the servers stateless helps with scaling out by simply adding more instances. The question is where in your architecture you intend to keep state. Usual choices are in a database or in the client. You just need a way of identifying which player you are working with. That can be looked up using the user's token. – Berin Loritsch Jul 10 '18 at 19:55
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).

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.