Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context (github.com)
Clickvote takes the hassle of building your own reaction components around your content.
Showing real-time updates of likes, upvotes, and reviews between clients.
Learn about your members through deep analytics.
Deal with an unlimited amount of clicks per second.
You can read the full article here:
https://links.github20k.com/click-vote
The open-source Library is here:
https://github.com/clickvote/clickvote
Please let me know your thoughts!
Am I building something useless?
57 comments
[ 3.6 ms ] story [ 148 ms ] threadMaybe if you’re running a “upvotes SaaS” the architecture makes sense but the given architecture diagram is more complicated than the production product I work on (https://notion.so).
Are real-time updates a feature users want here? I’ve never used a voting or rating site with real-time updates.
At least not the Kafka / Timescale feature. It would place nice if you were a bit bigger - a news website, a social media and so on.
How big do you think is "big"? I run a system that handles about 3k requests per second (~1:100 writes to reads). No caching, no Redis, just Postgres. One master and a hot standby for failover. It sits around 25% CPU, and most of that is from opening and closing connections rather than queries.
There's an important lesson in avoiding complexity for speculative reasons. Unless you have data that suggests more components materially improve the system, save yourself the heartache and build for the simplest system that meets your needs. You've built a dump truck when you probably only need a pickup truck, and while you might need more than a pickup truck someday, you're paying dump truck maintenance costs in the meantime (and your future needs probably look more like a King Ranch than a dump truck anyway).
What do you think about the idea?
If I’m gonna get that many clicks per second, it’s likely I’ll already have my own analytics system, queue system, cache architecture, application database. Why adopt this external code when I’ll spend more work integrating it into my application compared to building it myself?
If I’m small, why spend all the work or subscribe to your managed product when a very simple CRUD approach using only my app database and polling will suffice?
Anyways that’s my perspective. There’s probably some market out there but I’m not part of it, that’s all I’m saying.
In a few years from now. (I am talking about the managed version)
And yes - Twitter for example?
I also feel that your comment is slightly ironic, given the poor performance of Notion. I'm almost thinking (without having any clue about Notion's architecture) that Notion could benefit from a more complex architecture that prioritizes performance.
I don't mean to criticize, but the complexity of this is what I'd expect for something handling hundreds if not thousands of qps. Even then I'd expect you could probably fine-tune a Redis Cluster setup and cross out 2/3 of that architecture diagram. Hell, you don't even need WebSockets: a system like this polling for an integer or two should be scalable to tens of thousands of qps.
I plan to have it as a managed service in the future, which means that it will hold a lot of clients - some big, some small.
But I think I should def make another smaller version without Kafka and Timescale.
Actually am I crazy to thing that wouldn’t be the worst thing in the world? Tracking people across multiple sites without their informed consent is of course totally unethical spying, but if it is clear that they are consciously interacting with UI like yours and they know it is shared, that doesn’t seem so bad. (?)
And it could be nice if Pandora would start suggesting soundtracks to movies I’ve upvoted on Amazon or something like that…
You handwaved the idea of consent by saying it's "clear" to the user. But if there isn't a way to opt out then consent isn't addressed at all.
Stripe relied entirely on Mongo for storage and queueing at a scale that you'll almost assuredly never reach. That's probably inadvisable today, but the point is that the more systems you have, the more systems you need to maintain and the more things that can break and the more places you'll eventually find bottlenecks.
Ultimately, though, it would be nice to have a `.schema` equivalent in `psql` just as a convenience tool.
But now sure what to do on failures.
The moment that I need to have my own backend to manage some data, I can add the item rating data as well and your system becomes more complex than the built-in solution.
Are there any recommended good self-hosted alternatives? This looks nice but requires quite the stack of services.
It's something that I think about. It can be really great (in my opinion)
https://media.discordapp.net/attachments/1062038639112097872...
Happy to get some feedback on the product also :)
It seems very clear to me that many of these sharks have never tried to implement a similar system.
Unless you're only running one instance of this, it probably makes sense to scale back immediately otherwise your costs are going to balloon. Even then the horizontal scaling requirements of some of the "parallel" subsystems will get incredibly expensive fast.
Horizontal scaling will happen in any way if I just use a simple message queue.
a much simpler build system that's easy for people to adopt might have a higher chance of getting initial traction, and then you can add the layers only when they're needed. See YAGNI (You Ain't Gonna Need It) https://martinfowler.com/bliki/Yagni.html