Place Logic In Client Side or Server Side

RickBlaine

I'm building a small personal website and would like some advice please. Basically, they are 20 short sound files. Clicking a button will play one of those files randomly. Once played, that file will no longer be played. So in total, the user clicks the button 20 times, each time getting a new random sound (no sound can be repeated), a total of 20 clicks.

State isn't a concern. If the page is reloaded, we start over. There are no user profiles or accounts. No session cookies or anything like that.

My question is should the frontend (angularjs) keep track of this list of sound files or should it be done in the backend.

Client Side Approach

1. An array of file names is populated from an initial server call
2. When the 'Play' button is clicked, a name is selected randomly from the list
3. A server call is made to get this soundfile, e.g. getSoundFile('abc.mp3')
4. That filename is then removed from the list

OR

Server Side Approach

1. A collection is initially populated with sound file names
2. When the 'Play' button is clicked, a server call is made to get a random sound file, e.g. getRandomSound()
3. The server randomly selects a filename in this collection, removes it from the collection, finds the corresponding file and returns it to the browser.

Are there pros / cons to each approach? Personally, I would prefer to keep the front-end as light as possible so I am leaning toward the backend approach but I'm wondering if I am overlooking something that would make the frontend approach preferable. Thanks.

RickBlaine

OSI wrote: »

How do you plan on the back end keeping track of what it's already played for a particular client without any session info?

Sorry, I wasn't very clear. What I meant was there is no requirement for the session to be remembered if the browser is closed.I'm using .NET MVC.

Buford T Justice

RickBlaine wrote: »

Sorry, I wasn't very clear. What I meant was there is no requirement for the session to be remembered if the browser is closed.I'm using .NET MVC.

Yes, but if you have two web interfaces polling the same backend service call with no session id to distinguish them how do you expect the backend to differentiate one instance from another?

Also, the backend will have no knowledge that the page was reloaded.

RickBlaine

Buford T Justice wrote: »

Yes, but if you have two web interfaces polling the same backend service call with no session id to distinguish them how do you expect the backend to differentiate one instance from another?

Also, the backend will have no knowledge that the page was reloaded.

I'm using .NET MVC which I believe has out of the box session handling functionality. The default option stores session identification in memory.

In terms of page reloaded, I'll probably have some kind of initialization method call to the server that resets everything, assuming I'll go with the approach of having all the logic on the server side.

John_C

Keeping track of something on a per browser session basis sounds like it fits more neatly into the client side. You're talking about building 3 API calls (GET, UPDATE and RESET) vs storing a single object on the client.

Buford T Justice

RickBlaine wrote: »

I'm using .NET MVC which I believe has out of the box session handling functionality. The default option stores session identification in memory.

Yes, but if you make restful without an identifier the backend won't know which instance of the web ui is calling it.

BrokenArrows

The easiest way to do it is in the client side.

The better way to do it would be to do it on the server side. It allows for better control, scales better, allows you to enhance it in the future to add more files, keep track of sessions etc.

RickBlaine

BrokenArrows wrote: »

The easiest way to do it is in the client side.

The better way to do it would be to do it on the server side. It allows for better control, scales better, allows you to enhance it in the future to add more files, keep track of sessions etc.

Thank you. I'm looking for the better solution rather than the easiest one.

RickBlaine

Buford T Justice wrote: »

Yes, but if you make restful without an identifier the backend won't know which instance of the web ui is calling it.

Sorry, perhaps I'm misunderstanding something. ASP.NET will assign a session to a new client, and the response will include a cookie. This cookie will then be sent by the browser with subsequent requests which will allow the server to identify the client and use its instance.

Am I getting something wrong with this understanding?

Buford T Justice

I've not worked with .NET for a while, but the last time I did, there was no use of a cookie for state management, only tokens for auth, so I'm not sure.

off.the.walls

if you're doing it client side just use an object with a played property thats a boolean, select a random index, if played is true try again, keep going till you find an unplayed one.

Talisman

On the client side the simplest solution is to shuffle the array to create a random permutation. The Fisher–Yates / Knuth shuffle algorithm is generally used for this sort of thing.

function shuffle(array) {
  var currentIndex = array.length, temporaryValue, randomIndex;

  // While there remain elements to shuffle...
  while (0 !== currentIndex) {

    // Pick a remaining element...
    randomIndex = Math.floor(Math.random() * currentIndex);
    currentIndex -= 1;

    // And swap it with the current element.
    temporaryValue = array[currentIndex];
    array[currentIndex] = array[randomIndex];
    array[randomIndex] = temporaryValue;
  }

  return array;
}

You only need to perform the shuffle once on page load and afterwards your play button iterates through the array returned.