6

I want to make it possible to edit shared todo lists in real time.

There's already a REST interface, and it's possible to send updates to the server - add items, mark items as done, etc.

For the client to get these updates immediately, I did some research, and it seems that the best approach would be websockets, as they are quick and reliable. Push notifications on the other side can take "a few seconds" and are not reliable. I think I also saw something about "HTTP broadcasting" which did look more suitable for videos and things like that. Can't find it again.

So I was wondering, first, if websockets are really the best fit for this, second, if it's a good practice to use this in combination with REST - that is, I do the "push" from client A to server using a REST call, and then do the "push" from the server to client B using a websocket. Of course client B can also send updates to the server which have to be pushed to A (and other possible participants). So maybe it would be simpler to open websocket connections for both and throw out my REST code. On the other side a list can also have only 1 participant (the current user), in which case a websocket is not necessary, so maybe I could let these users use REST and switch to websockets only when there are more than 1 participants?

Does a mix of REST/websockets make sense for this application? Or should I stick to one or the other?

4
  • Ok I deleted it in StackOverflow but I assume the -votes will stay, great. Edit: The -votes are gone, thanks.
    – User
    Commented Nov 20, 2015 at 20:53
  • What database are you using? This could change how you handle things.
    – Sirisian
    Commented Nov 20, 2015 at 21:16
  • MySQL, why is that important?
    – User
    Commented Nov 20, 2015 at 21:17
  • 1
    Some people prefer to use database triggers that fire off the push notifications. This allows multiple services to access the database and any change to the data (even manually by someone running a database command) results in push notifications to services listening for changes. Not completely necessary, but it can be rather resilient.
    – Sirisian
    Commented Nov 20, 2015 at 21:34

2 Answers 2

2

You could use all 3. Use the REST API for posting information to the server, websockets for immediate updates, and fall back to push notifications to the end user if the app isn't running (and the user wasn't notified over the websocket connection).

Of course, the REST API isn't strictly needed since you can perform the same server-side actions using websockets that you could with the REST API. But whether that makes sense or not really depends on your server piece. Since you already have the REST API, there's no major urgency for you to rewrite it for websockets. But you can certainly start migrating the functionality to use websockets with the goal of eventually removing the use of the REST API.

0

If you want a complete WebSocket solution (there's no real need for REST unless you already have some REST framework on the server-side), there's an implementation of the shared todo canonical demo ToDoMVC by one of the Kaazing engineers that uses pub/sub with WebSocket. Its written in Angular and uses a universal messaging API.

http://kaazing.org/demos/todomvc/todo

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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