Nobody is using Redux any more, and it's even publically discouraged by the creator. It's a legacy system and including it in your problems list just makes me think you have no React experience and no idea what you are talking about (beyond technical yapping also Redux as a product still achieved what it tried to solve so your dx doesn't even matter).
Firebase in this context is just a database and how you poll data on client or server from it. Nonsensical reference again.
Hi. I'm the current Redux maintainer, and have been since Dan handed it over to me in mid-2016, one year after he created Redux. It's also worth noting that Dan never used Redux on a real app (that I know of), whereas I've spent years maintaining Redux and Redux Toolkit and designing APIs based on the needs of our users.
Redux is still by far the most widely-used state management library in React apps. Some of that _is_ legacy usage, sure. But, our modern Redux Toolkit package has ~30M downloads a month. Zustand has become very popular as a client-side state option, and React Query is now the default standard data fetching tool, but you can see that even just RTK is still right up there in monthly NPM downloads:
I've frequently talked about the original reasons for Redux's creation, which of those are still relevant, and why Redux is still a very valid option to choose even for greenfield projects today:
So I have been building quite a few apps and n8n workflows that were using a lot of LLM requests. I was building pretty much in the dark, just getting some (partly delayed) usage stats from each provider separately. From that arose a need for some proper request logging, stats, filtering, scoping the requests to the various workflows, and rate limiting. So I've built that for myself (see link).
Bottom line here how it helps me is:
1. Helps me understand my requests from various apps and workflows (e.g. prompting, revisiting past requests, scoping the requests, any meta data stored, charts to visualize metrics). It's completely provider agnostic, too.
2. Gives me an understanding of how much I spend exactly on single requests, any workflow or parts of a workflow, apps, which provider I spend how much on, etc.
3. It gives me the ability to rate-limit my requests, and that can be done even by grouping requests from different providers. Essentially, I'm tagging every request, so if I make one to Gemini and one to OpenAI and give them the same tag, I can put a rate limit on the tag that will stop further requests to any of the used providers once the limit is hit.
4. It gives me an understanding how profitable a request or a group of requests is (for example, I can attach a stripe customer or sale id to the requests I make. Then I create a payout and attach it the same tag, matching requests with the income and calculating income / expense ratio).
Not yet sure if I want to take it further in terms of making it accessible to others, but I've put up a waitlist for now and recorded a demo video. Maybe there is some interest.
The script is (obviously, as you can see the hosted source code on Github) open source. Indexnow is the internal endpoint that those search engines offer to submit urls to them. Not supposed to be open source, no point in having an API backend open sourced for this purpose.
Yes. Nothing wrong with that, when you're just trying to inform a broad audience. Not well suited for giving individual advice that is actually helpful.
You're right. I thought about it and I'm more trying to see how they work and what are their differences. It's surprising sometimes. They each have their strengths. For example, if you like reddit answers Meta AI seems to best at that.
Workoholic doesn't mean 'unhappy', yes, but how does procrastination not mean 'not working'? In this context, it litterally means 'postponing the work'.
Firebase in this context is just a database and how you poll data on client or server from it. Nonsensical reference again.