What it says on the tin. What kind of mechanism do you prefer for your web APIs? Where would you use it? Where wouldn't you?
Examples:
- gRPC
- JSON over HTTP (RESTful, usually)
- Binary over WebSockets
- Custom UDP (e.g. for real-time game networking?)
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (6)
Depends on the thing but I've always found HTTP easiest to work with due to the built in request/response flow that lends itself well to async/await programming constructs. It takes more work to achieve the same thing with, for example, web sockets.
Have you ever encountered difficulty mapping HTTP primitives (GET/POST, etc) to your API? Like a get-and-delete operation, or something of the sort.
Yeah, sometimes it's not straightforward. PATCH often helps me in those cases since its semantics are very flexible. "A set of instructions on how to modify a resource" can do just about anything.
once I was working on an app with protobuffer over websocket. we had web and desktop/electron clients. it was ok, but chrome http networking devtools are much better than for websockets.
I think websockets are a overhead when starting a project. And of cause websockets are needed for realtime apps. Having websockets from the beginning has the potential to turn every RPC request into an app with realtime updates.
I also worked on apps where sockets where added afterwards. With WebSockets or FireBase. But they never reached the level of realtime interactivity, that started out with Sockets.
I thinm the reason is not only technical, but when starting with websockets, it puts every developer (including management) to a different state of mind, always thinking about realtime.
Interesting note about setting perspectives! Did you end up having to reimplement things like timeout/retry? Did any of these projects involve wrapping messages and passing them on to another process a la microservices? How was the experience doing that?
the websocket framework was
pomelo. it can have many frontend server where websockets clients connect, and backend server that execute the application code. the framework is no longer maintained, so i can not recommend it.The framework was developed in china, and most documentation and community was in chinese. (i live in shanghai). I would say for some time it was ahead if its time, and developed at netease(chinese internet giant that developed Diablo Immortal with blizzard/microsoft)
but the framework did not age well. The rpc handler can not be async functiona that just return a promise.
And when returning data that dit not have the shape of the protobuffer message, it logged an error of 'invalid message' but did not say what API it was,... it was always happy debugging.
today i would say just use socket.io instead, and using redis it is directly scalable to some degree. I think you can implement retry and timeout in about 20 lines of code. The use of the mongoDB watch command can also be interesting. personally I would leave the fingers off of metheor js.
The project was from a time before docker got so popular. The pomelo framework named it
Duck server. a kind of framework dependent microservices, living all in the same repisitory/code-base. We developed a custom solution forzero downtime deployment. an old version server first finish serving the current connections and sessions, before shutting down. While new version servers already got started, and all new traffic got routed to then(connection and network routing done by the pomelo framework).so yes, interesting approach, that needs a more modern foundation today. and great when very high levels of realtime interactivity are desired/needed.