It's funny that using the class instead of the data attribute works reliably. But I can't figure out why exactly, because the styles for the data attribute are even higher than the styles for the class

Looks like nope 🥲

If there is a theme entry in localStorage, it does not flicker, if there is not - it flashing

Nice try, Rowling, nice try...

I currently have a rate limit configured on my firewall, disabled AI scanners, captchas for suspicious agents, and several specific rules for countries and IP addresses.

I use Vercel, but I think you can connect domain to CF and set up the same thing in free plan

I assumed it should be cheap, but I implemented custom backend routes and metadata generation at the server level. Rendering is done only on the client. This offers little SEO potential, but it's better than nothing.

I think I could also try making some requests directly from the client to bsky API

I've also been noticing abnormal activity in recent weeks and tweaking my firewall settings.

@zeu.dev have you analyzed your traffic?

I can tell from Atsky that such clients, among other things, are very popular for bots and scanners. This means millions of additional requests, and implementing support and stability on a self-hosted system will also be painful (and probably expensive)

I just noticed I left my vitamins in the sun again and got angry... A minute later, I started laughing

* Yes, that's the sun outside the window in London. It's not Photoshop, just a bit archival *

* Just don't tell them about the local matured Christmas pudding... *

Working with the demo also revealed that the package didn't connect to Vite projects out of the box because the ESM wasn't fully configured. Now everything's ready

I'll look into ways to improve support even further

You can try it at contection.dev. The video doesn't really convey how it works

Yeah, I remember, that was fun. Thanks for the reminder - I'm also curious if the whole system is so reliable that the request will only come in once or twice.

Not client-side caching, not back-end checks, not rate limits – but the expectation that it will only be executed a couple of times.

I can't find an answer, but it looks like this limit was only based on some agreement or basic block in the UI (I hope there was at least a check at the backend level)

It's interesting that the Internet decided to crash when the parameter size was exceeded, rather than process the acceptable part

I also worked around this by thinking up a variant of feature flags - where you have an intermediary between the client and the server, and it enriches the request with flags data via cookies

I remembered one interesting problem: after updating next.js and React, our site completely crashed.

So... it turned out that the headers had exceeded the allowed size (there were too many link headers)