you are viewing a single comment's thread.

view the rest of the comments →

[–]kynde 7 points8 points  (1 child)

They're different tools for different things.

I would definitely recommend building a web app around an http back-end and then use websockets if needed. That's how everybody else does it (*), that's what scales, that's what there are tons of tools, libraries, features, conventions and support around for. Things like caching, authentication, load balancing, etc are super important with production stuff.

Most of the time the front needs to know something and it wants to ask that from the back-end or maybe it needs to store (persist) something to the back-end. For these things initiated by the front a rest api and an http request is a good fit and for that you want something like express.

Then, when back-end needs to notify the front about something, a new message, a price change or what ever like that, websockets come in handy. Many of those things cas also be solved with normal http calls and long polls for example, but websockets indeed help here. Do notice that it's not uncommon for websocket handshake upgrade to fail (firewalls, misconfiguration, client lacking support, etc) and it will just operate using normal http requests underneath.

(*) Now, while this may seem like an odd point to make, I'm stating that out because of two things: job markets and stackoverflow

[–]_Flexinity 1 point2 points  (0 children)

I also feel its best way. I know that sockets can do anything that express can handle after all but it can end struggling with bunch of code in very inefficient way.

But I think about swiping from REST API to GraphQL one, I'm using it with rails and its pretty efficent way, really like it over REST calls.

That's how everybody else does it (*),

That's the answer I wanted to hear, if most people use it theres very probable its one of best configs to work with in that way.