OpenResty vs Socket.IO: What are the differences?
What is OpenResty? Turning Nginx into a Full-fledged Web App Server. OpenResty (aka. ngx_openresty) is a full-fledged web application server by bundling the standard Nginx core, lots of 3rd-party Nginx modules, as well as most of their external dependencies.
What is Socket.IO? Realtime application framework (Node.JS server). Socket.IO enables real-time bidirectional event-based communication. It works on every platform, browser or device, focusing equally on reliability and speed.
OpenResty belongs to "Web Servers" category of the tech stack, while Socket.IO can be primarily classified under "Realtime Backend / API".
OpenResty and Socket.IO are both open source tools. It seems that Socket.IO with 46.7K GitHub stars and 8.53K forks on GitHub has more adoption than OpenResty with 7.06K GitHub stars and 978 GitHub forks.
According to the StackShare community, Socket.IO has a broader approval, being mentioned in 555 company stacks & 385 developers stacks; compared to OpenResty, which is listed in 37 company stacks and 4 developer stacks.
What is OpenResty?
What is Socket.IO?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose OpenResty?
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using OpenResty?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
At Kong while building an internal tool, we struggled to route metrics to Prometheus and logs to Logstash without incurring too much latency in our metrics collection.
We replaced nginx with OpenResty on the edge of our tool which allowed us to use the lua-nginx-module to run Lua code that captures metrics and records telemetry data during every request’s log phase. Our code then pushes the metrics to a local aggregator process (written in Go) which in turn exposes them in Prometheus Exposition Format for consumption by Prometheus. This solution reduced the number of components we needed to maintain and is fast thanks to NGINX and LuaJIT.
We use nginx and OpenResty as our API proxy running on EC2 for auth, caching, and some rate limiting for our dozens of microservices. Since OpenResty support embedded Lua we were able to write a custom access module that calls out to our authentication service with the resource, method, and access token. If that succeeds then critical account info is passed down to the underlying microservice. This proxy approach keeps all authentication and authorization in one place and provides a unified CX for our API users. Nginx is fast and cheap to run though we are always exploring alternatives that are also economical. What do you use?
I use Socket.IO because using HTTP requests for a real-time multiplayer game just blows! Even with websockets, I had to scrunch the data being transmitted down to a bare minimum, and do some cheap compression tricks so that I can send data in JSON format. Otherwise, I would have to resort to sending binary data. I may end up doing that anyway when the time comes that I need to scale.
How do I use it? Each client opens a socket connection at startup. The server keeps track of these connections, and sends each client the visible portion of the Playfield repeatedly. The clients render this information, while sending requests and commands to the server (join,turn,fire,thrust,bomb,viewport change,etc.) in response to the player's actions. The server uses that to make adjustments to the player's ship on the Playfield.
Where we have browser support (recent Chrome, Firefox, and Safari), we make a WebSocket connection so that the server can push changes made by other people down to browsers listening on the appropriate channels. We use a modified version* of the Socket.io client and server libraries that allows us to keep many thousands of open WebSockets on each of our servers at very little cost in terms of CPU or memory usage. So when anything happens to a board you’re watching, that action is published to our server processes and propagated to your watching browser with very minimal latency, usually well under a second.
Socket.IO has a decent community footprint, including integrations with popular JS frameworks, and has fallbacks to maintain an app's services if websockets are not available for some reason. Websockets are an important factor in most of the web-facing apps I build, to provide asynchronous two-way communication between the app and whatever server or data source it is connected to.
Another one that we're not using, yet. But have realtime data updates within our applications and the central API will be a great bit of functionality that gives our clients more control and keep them informed of changes and updates in their stores, in real time.
Socket.io is used as our current multiplayer engine. The existing engine is very simplistic and only utilizes the websocket+http fallback transports and serves as a generic world/zone/screen grouping mechanism for displaying users to each other.