overture
Mercure
overture | Mercure | |
---|---|---|
3 | 19 | |
708 | 3,748 | |
0.3% | - | |
7.9 | 8.4 | |
25 days ago | 4 days ago | |
JavaScript | Go | |
MIT License | 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.
overture
-
CSS lengths in Gecko are limited to 17,895,697 pixels (2010)
Fastmail shows lists of messages using a progressively-loaded list, where each item is of a consistent height (88px for me, but it can be a few other values too, depending on your configurationâI think 51px is the default). This means that the scrollbar is real and accurate, and you can seek to any point in your mailbox easily (provided your platform allows interacting with the scrollbar, which largely means âon desktop platformsâ). But this does cause problems for very large mailboxes, because browsers only support finite lengths.
A few years back, while I worked at Fastmail, we had a ticket come in from an IE user that they could suddenly only access the first few messages in their mailbox. Trouble was theyâd gone over IEâs limit, and IE just ignored the entire height declaration in that case, and so you ended up with only the initially-rendered list items available.
The limits I found:
⢠Firefox: ignores declarations that resolve to a value higher than 17,895,697 pixels (which is a bit more than 2²â´).
⢠IE: ignores declarations that resolve to a value equal to or higher than 10,737,418.23 pixels (2Âłâ° â 1 hundredth pixels).
⢠WebKit: clamps values somewhere around 2²⾠(~33,554,432) pixels; clamping means you donât need to worry about it so much, since that was the best workaround in other browsers anyway.
And so we ended up with the workaround code at https://github.com/fastmail/overture/blob/41cdf36f3e7c8f0dd1... (the Firefox check was of much older vintage, I just added the IE case). (Nowadays, the IE part is gone again because IE is gone, hooray!)
So yeah, it actually only took about 200,000 messages in the list to hit this limit and fall over, or subsequently just make the bottom of the mailbox inaccessible. 200,000 messages in one mailbox is uncommon, but not at all unrealistic, especially in an âAll mailâ sort of mailbox.
-
Defensive CSS
One uncommon place where clipping is justified at the design level: lazy-loading but finite lists. Iâll use Fastmailâs webmail (on which I worked a few years back) as an example. I could load a list of a hundred thousand emails, and each message in the list is 88px tall (containing four lines of textâapproximately, sender and date, subject, and two lines of preview, with truncation on each), so the list container is made to be 8,800,000 pixels highš, and I can use its scrollbar to immediately jump to any place, and it will figure out which messages to fetch and render based on the scroll position. If the subject line were wrapped, which would be nice at times, youâd lose this ability: youâd have to guess the approximate height of each element, and your scroll positions will be imprecise and youâll have to make messy adjustments from time to time. Overall it generally wonât be too bad so long as thereâs not too much variation in them, but itâs definitely still inferior.
š Browser do have limits on how large you can make containers, and handle excess in different ways. IE had the lowest threshold of failure at around ten million pixels, beyond which point it would ignore values; the workaround I implemented in https://github.com/fastmail/overture/commit/8d01c74d8c5d4ae0... came as a direct result of a customer reporting that scrolling was broken in IE in their mailbox with a couple of hundred thousand emails. Firefox breaks a little after 2²ⴠpixels, also ignoring values, so itâs still covered in https://github.com/fastmail/overture/blob/0c9828a5b77ad14383... (note the IE stuff is gone because IE is dead! :-) ). Chrome accepts larger values, but clamps them to about 2²⾠pixels.
-
Server-Sent Events: the alternative to WebSockets you should be using
It is, however, interesting to note that Fastmailâs webmail doesnât use EventSource, but instead implements it atop fetch or XMLHttpRequest. An implementation atop XMLHttpRequest was required in the past because of IE, but it still deliberately doesnât use EventSource; my foggy recollection from a few years ago is that it had to do with control over timeout/disconnect/reconnect, and handling Last-Event-ID, plus maybe skipping browser bugs in some older (now positively ancient and definitely unsupported) browsers. The source for that stuff is the three *EventSource.js files in https://github.com/fastmail/overture/tree/master/source/io.
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?
wa-automate-nodejs - đŹ đ¤ The most reliable tool for chatbots with advanced features. Be sure to đ this repository for updates!
Socket.io - Realtime application framework (Node.JS server)
FiraCode - Free monospaced font with programming ligatures
websocket - A fast, well-tested and widely used WebSocket implementation for Go.
dom-examples - Code examples that accompany various MDN DOM and Web API documentation pages
Centrifugo - Scalable real-time messaging server in a language-agnostic way. Self-hosted alternative to Pubnub, Pusher, Ably. Set up once and forever.
hasses
amqp091-go - An AMQP 0-9-1 Go client maintained by the RabbitMQ team. Originally by @streadway: `streadway/amqp`
markwhen - Make a cascading timeline from markdown-like text. Supports simple American/European date styles, ISO8601, images, links, locations, and more.
NATS - Golang client for NATS, the cloud native messaging system.
rsocket-java - Java implementation of RSocket
sarama - Sarama is a Go library for Apache Kafka. [Moved to: https://github.com/IBM/sarama]