SPA CRUD operations: HTTP requests vs websockets

You will use websocket/channels anyway for feedback.

So, it is more like how do You want to CRUD your data, through an API, AND/OR through websocket. This is not exclusive.

The API is more compatible, because You can use any http client.

But if You don’t need to expose an API, You can go websocket/channel all the way down.

Some previous threas that might contain interesting info in this forum (search for “SPA”):

This might be of interest also:

maybe the time has come to treat WebSockets as first-class citizens and to start
introducing RESTful HTTP verbs to WebSockets (as naming conventions for 
events). This is very new territory, but there are some important benefits to
using REST over WebSockets:

To be honest, I would probably broadcast only ids over websockets (for realtime stuff) and then retrieved the full data using regular HTTP API. Using HTTP has a lot of benefits that are often overlooked - extremely easy reporting through a multitude of tools, easy caching, easy rate-limitting, and more.
If the data is small, then it might make sense to send it all through websockets, but for big payloads the overhead of HTTP is easily outweight by the other things, primarily caching - even more so for public resources.

Thank you for your answers. As an HTTP API is not absolutely required in my case, I have some trouble to make up my mind and needed more input, you are very helpful in this regard.

@kokolegorille
As said, an HTTP RESTfull API is not required so far, but I would like to avoid having both an HTTP API and a websocket API with redundant features. Hence my hesitation. The clients compatibility is a good point.

@StefanHoutzager
Thank you for the links:

• json-pure is interesting as this would allow me for example to use a websocket only API at first but still being able to add support for an HTTP endpoint later if required, even if caching is mostly impossible in this case (and realtime feedback limited).

• Why I No Longer Use MVC Frameworks article from Jean-Jacques Dubray raises some interesting considerations about GraphQL (that I am reluctant to use at this point). Also I may take his SAM pattern into consideration as I use elm for the frontend and it seems easy to implement using The Elm Architecture, even if it does not enforce it by default (as stated in this comment).

@michalmuskala
Thanks, you raise some strong points there. I am worried about performance as the clients have specific permissions that must not allow them to receive the same messages (and client filtering would be considered as a security issue). Using channels, this will require to use intercept on all messages or using per-client channels, and using HTTP, this will make intermediary caching mostly pointless (almost no public resources). But browser caching could still be possible and should indeed be taken into consideration, as well as tooling.

Concerning what mr. Dubray says I would carefully check what he writes. He likes to ride high on his horses and produces lots of quite uncomprehensible prose, in my opinion.

Well, at least it seems to me that his considerations about APIs being too much dedicated to frontend views and therefore unstable because of it make sense, even if at the end, practical “what works” will win for me. And I actually use the functional approach to adapt the model data for views (which is quite natural in elm).

Also again in elm, it is tempting to include view states in the model, which can become confusing. Having separated “view states” (even if it is one field of the model record) is an approach. Another one is to use “sub-models” as in the elm-spa-example from Richard Feldman, but it is not always wanted to loose a SPA “page” state when changing “page”. Anyway this might drift too much away from the intial intention of the post.

@StefanHoutzager I forgot but I also did not take enough into consideration so far the point in REST over WebSockets instead of HTTP about the corporate environments compatibility with websockets.

I will move to wss:// (it seems that using SSL in phoenix should make websockets also use SSL) and hopefully I won’t meet a customer using proxies with fake root certificates (I actually worked some years ago in a company using this, urgh…). Thanks for the link.

I’m (eventually) going for the same idea. I’m just not quite comfortable with my current Elixir skills at this point to get there, but I will get there.

Have a look at this Node.js project Feathers for some ideas. It uses websockets for it’s realtime updates. This is where I was before coming to Elixir and felt that something akin to Feathers could be done much better using Phoenix/Elixir/Erlang/OTP.

Just food for thought

Anything happaning on this front? I am on the same track - feathersjs is really very interesting, but with Elixir backend it would be the stack for the next ten years.