glimesh.tv
Mercure
glimesh.tv | Mercure | |
---|---|---|
5 | 19 | |
453 | 3,748 | |
0.4% | - | |
5.7 | 8.4 | |
10 months ago | 5 days ago | |
Elixir | Go | |
GNU General Public License v3.0 or later | GNU Affero General Public License v3.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
glimesh.tv
- Glimesh is a next gen live streaming platform built by and for the community
- The future is coming...
-
Glimesh|(Twitch Alternative) Next-Gen Live Streaming
Source Code
-
We Got to LiveView
We use Phoenix and LiveView to power all of our non-video interactions on Glimesh.tv[0] and the immediate out of the box features and performance are unmatched. LiveView allowed us to get a completely real time updating channel where streamers can edit their metadata (game, title, viewer count, etc) and all of the viewers can see it in real time. Not to mention we implemented a distributed chat system that sends message updates in real time to both browser clients and API clients. Both of these features combined amount to less than 1000 lines of code and "just work" across multiple web nodes.
It can be daunting to jump into such a strange world as a LiveView environment may look (Elixir syntax, OTP terminology, etc) but honestly once you dig in deeper, everything just makes sense. LiveView (and HEEx) continue to be very simple to understand abstractions on top of the rock solid OTP platform. It's a joy to build real time applications using it, and I very much appreciate the "developer experience" focus both Chris & Jose have for us Elixir devs!
I'm excited for the launch of Phoenix 1.6 and HEEx is shaping up to be a complete replacement for your traditional SPA + Backend API, and using one consistent language for your full stack really has very freeing & powerful benefits, especially for small teams!
[0] https://github.com/Glimesh/glimesh.tv/
-
Glimesh is an open source, next-gen live streaming platform built by the community that puts streamers & community first and not the advertisers. It is currently in alpha.
You're also right on the subscription statement in the FAQ, I've submitted a bug for us to fix here: https://github.com/Glimesh/glimesh.tv/issues/687
Mercure
-
PHP homies, I hear ya.
Are you aware of things like websockets and mercure.rocks?
-
What is the best way to write a dedicated server?
It could be implemented with STOMP, or Mercure (goes well with API-Platform, written in PHP/Symfony), you could write your own with the help of nchan and scale it via Redis. If it's a web service, the best practices for operating and scaling are well established, Godot then just becomes another client.
-
What to use to replace laravel web sockets?
You can try https://mercure.rocks/.
-
OpenAI server-sent events supported chatbot
It's worth looking at something like Mercure , which is used by API Platform
-
laravel activity feed
Pusher might be one of these systems, Mercure is another one (which you can host yourself). Mercure has good documentation and some examples in various languages, including PHP: https://mercure.rocks/docs/ecosystem/awesome#examples.
-
Golang updating the front-end with almost real-time events from the backend server
You can use Mercure https://mercure.rocks/ , Mercure uses http2.
-
Centrifugo v4 released – with own WebSocket emulation layer, optimized client protocol, unified SDK behavior, experimental HTTP/3 and WebTransport support
I actually was thinking about this when I saw https://github.com/dunglas/mercure project to become a Caddy plugin. But I did not find enough reasoning to try this with Centrifugo at that point, and still... Seems awesome from one side - tight integration with a web-server, no extra network between LB and Centrifugo. But will this be useful in practice and find its users? 🤔 That's the question I don't have an answer yet.
-
How would I automatically update how much users are signed up for each group?
Polling is kind of ok (data might change between poll events), but real-time updates are better. So If you don't mind adding an extra service, then take a look at mercure.
- Mercure: Real-Time Made Easy
-
Announcing GraphQL Yoga 2.0!
Two more questions: - Am I to understand The Guild now recommends GraphQL Yoga over Helix? - Could something like Mercure be included in the recipes ? (this would be a nice solution for serverless)
What are some alternatives?
contex - Charting and graphing library for Elixir
Socket.io - Realtime application framework (Node.JS server)
live-paint - Demo pixel painting webapp with realtime updates across all connected tabs and browsers
websocket - A fast, well-tested and widely used WebSocket implementation for Go.
stimulus_reflex - Build reactive applications with the Rails tooling you already know and love.
Centrifugo - Scalable real-time messaging server in a language-agnostic way. Self-hosted alternative to Pubnub, Pusher, Ably. Set up once and forever.
torch - A rapid admin generator for Elixir & Phoenix
amqp091-go - An AMQP 0-9-1 Go client maintained by the RabbitMQ team. Originally by @streadway: `streadway/amqp`
webtransport - WebTransport is a web API for flexible data transport
NATS - Golang client for NATS, the cloud native messaging system.
Absinthe Graphql - The GraphQL toolkit for Elixir
sarama - Sarama is a Go library for Apache Kafka. [Moved to: https://github.com/IBM/sarama]