Google App Engine vs Socket.IO: What are the differences?
Google App Engine: Build web applications on the same scalable systems that power Google applications. Google has a reputation for highly reliable, high performance infrastructure. With App Engine you can take advantage of the 10 years of knowledge Google has in running massively scalable, performance driven systems. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow; 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.
Google App Engine can be classified as a tool in the "Platform as a Service" category, while Socket.IO is grouped under "Realtime Backend / API".
Some of the features offered by Google App Engine are:
- Zero to sixty: Scale your app automatically without worrying about managing machines.
- Supercharged APIs: Supercharge your app with services such as Task Queue, XMPP, and Cloud SQL, all powered by the same infrastructure that powers the Google services you use every day.
- You're in control: Manage your application with a simple, web-based dashboard allowing you to customize your app's performance.
On the other hand, Socket.IO provides the following key features:
- Real-time analytics - Push data to clients that gets represented as real-time counters, charts or logs.
- Binary streaming - Starting in 1.0, it's possible to send any blob back and forth: image, audio, video.
- Instant messaging and chat - Socket.IO's "Hello world" is a chat app in just a few lines of code.
"Easy to deploy", "Auto scaling" and "Good free plan" are the key factors why developers consider Google App Engine; whereas "Real-time", "Event-based communication" and "Node.js" are the primary reasons why Socket.IO is favored.
Socket.IO is an open source tool with 46.9K GitHub stars and 8.54K GitHub forks. Here's a link to Socket.IO's open source repository on GitHub.
Rainist, PedidosYa, and Trello are some of the popular companies that use Socket.IO, whereas Google App Engine is used by Snapchat, Movielala, and Wix. Socket.IO has a broader approval, being mentioned in 560 company stacks & 395 developers stacks; compared to Google App Engine, which is listed in 481 company stacks and 343 developer stacks.
What is Google App Engine?
What is Socket.IO?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Google App Engine?
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
With Cloud Endpoints you can create and deploy mobile backend in one hour or less. And it is free (until you need extra scale). I would not recommend to use Java - python is faster and has all new appengine features.
Pros: everything is in one place: task queue, cron, backend instances for data processing, datastore, mapreduce. Cons: you cannot easily move your code from GAE. Even with special 3rd party services.
With Cloud Endpoints you can create and deploy mobile backend in one hour or less.
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.
PaaS for back-end components, including external data ingestion APIs, front-end web service APIs, hosting of static front-end application assets, back-end data processing pipeline microservices, APIs to storage infrastructure (Cloud SQL and Memcached), and data processing pipeline task queues and cron jobs. Task queue fan-out and auto-scaling of back-end microservice instances provide parallelism for high velocity data processing.
checking a swap require a lot of cpu resource, roster normally come out same day of month, every month, at a particular time. Which make very high spike, our flag ship product, iSwap, with the capability looking swap possibility with 10000 other rosters base on user critieria, you need a cloud computing give you this magnitude of computing power. gae did it nicely, user friendly, easy to you, low cost.
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.
App engine fills in the gaps in the increasingly smaller case where it's necessary for us to run our own APIs.
Very easy to make cloud computing of ML models , and use containers like Kubernetes.