Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context (github.com)

123 points by nevodavid10 ↗ HN
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 ] thread
I can see it being very useful for early-stage products and A/B testing, so keep going, congrats!
Thank you so much Happy to hear about A/B testing idea!
Is the application architecture diagram a satire? It needs a lot more justification! Your documentation should very clearly explain why `upsert into user_rating (user_id, rating, thing_id)` doesn’t work at scale, and the limit where it breaks down.

Maybe 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.

I am failing to understand your question insert into user_rating will work. This is what it's doing now?
I think they mean, why introduce this new piece of infrastructure when you can create this internally with a singular table and probably a queue somewhere if we're being really fancy.
I think you can def do it on a low scale. You would not need this tech.

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.

> 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).

It's not a big problem to create another version without Kafka, and use Postgres :)

What do you think about the idea?

I don't want to tell you what the right answer is for your project. But my dad always said "Use the right tool for the job." And if you don't know what tool is right, test some tools and see which one works best.
How many clicks per second on an item would justify this architecture? Ballpark numbers and napkin math estimates is fine - again it would seem reasonable if justified.

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.

My main question was, how many will I have + what the architecture should be for other developers to trust me to handle their load?

In a few years from now. (I am talking about the managed version)

I think you're absolutely right! What OP tries to bravely build here, does not need such a complex architecture, even if they want to turn it into a SaaS solution.

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.

Why do you need Kafka, Redis, Mongo, AND Postgres? Arguably it could all be done with Postgres or Redis: both have great pubsub implementations. But what could you possibly need two databases for and a queue implementation alongside a popular backend for queues?

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.

As for Postgres, I chose Timescale because you can easily change it at any time for Postgres.

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.

When it is a managed service, will a single individual be feeding into a single sort of taste profile over multiple sites?

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…

It's hard enough to view the content I want to see when everyone has "smart" content feeds shoving ads in my face. I work hard to isolate what I look at on Amazon from what I see on YouTube so marketers don't ruin the little bits of the web I'm able to enjoy intentionally. Creating cross-site bleed of account information behind the scenes just makes everything worse for the user who can no longer drive your app...they just have to plop in and let it drive them.

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.

Even if you were managing this for third parties, there's no reason to assume your scale would necessitate this complexity. One of my Postgres databases stores analytics data for podcasts. 800gb worth in two tables. It's just vanilla Postgres with indexes. P90 queries complete in 100ms. I serve >10k customers with one write instance and one read-only replica. Some podcasts get thousands of listens per second at peak times.

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.

You chose timescale because you can swap it out for Postgres? Why not start with Postgres then? Is there anything timescale provides that is beneficial over Postgres?
That is an absurd set of technologies to choose. The cost of having multiple persistent backends is so high I’ve never understood the motivation.
[flagged]
Some tools are good for some jobs. Other tools are good for other jobs. There's no "war".

  pg_dump --schema-only --table=tablename databasename
I have to say that this style of pointless tech flamewar is actually quite refreshing to encounter. It's like Slashdot in the old days Linux v BSD. Someone fires off a command or a patch that adds the functionality. Sort of nostalgic.

Ultimately, though, it would be nice to have a `.schema` equivalent in `psql` just as a convenience tool.

This is an awfully petty hill to die on, especially for this website. The material difference between Postgres and MySQL for the overwhelming majority of users is insignificant. They're both good pieces of software and there are hardly any features missing in either that anyone who's not a DBA would miss when comparing one to the other. It's like arguing against using Firefox because Chrome "won the war". Who do you think you're convincing?
Even better is to just use Clickhouse (maybe Kafka if there are lots of inserts and async_insert isn't sufficient) and Postgres.
Thought about Clickhouse without Kafka even because it can handle streams of data.

But now sure what to do on failures.

I love how in the age of good old PHP, Django and alike this would be insanity. But with serverless it makes sense I guess.
Can you elaborate on this? ^_^
The point is that this crazy architecture could (perhaps) only be justified if all my backend is outsourced to external serverless points.

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.

I am going to make a lighter version of it! Just redis, websockets and Mongodb!
Nonsense! You could build this with Django Channels with no problem. There's nothing about this system that makes Django (or really any other framework) a poor choice.
My point was quite the other way around. With those legacy tools it is very simple and most people would just build the feature. Serverless adds more friction if you don’t have a suitable backend. And this makes sense then.
I actually made something similar where you can add likes and reviews to any URL. It’s at voterr.io but I never really focused on trying to make it take off
I've been looking for something to integrate in my site that just lets unauthed users to add upvotes, downvotes, and maybe some extra ones like 'recommend' or a few general ones like 'cat/dog'. Dont need any alaytics or extras.

Are there any recommended good self-hosted alternatives? This looks nice but requires quite the stack of services.

Up- and downvotes without authentication will be abused.
You can use something like fingerprint.com

It's something that I think about. It can be really great (in my opinion)

For me, this looks like it's useful for those wanting to create a new Reddit or similar style site. It removes the need to build a scalable upvote system.
In my weird dream, people will attach likes to everything :)
Congratulations for creating a product that I believe will most certainly find a market. Like the others, I believe you could dramatically simplify the architecture, but mad props for just publishing your MVP, and throwing it to the sharks of HN.

It seems very clear to me that many of these sharks have never tried to implement a similar system.

Thank you! I think the idea is innovative and can be expanded. It's really a small small MVP. To see the community adoption.
When designing a tool, scalability should be a feature not a requirement. There isn't so much value in creating scalable tools these days as they exist in abundance. What is rarer and more useful are tools that are easy to use at small scale that work without minimal modification and headaches at scale.

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.

I was thinking of using something like Upstash for serverless redis and Kafka so it won't be so expensive.

Horizontal scaling will happen in any way if I just use a simple message queue.

You should put React library to your title, it makes it easier for potential users.
It should over time support all frontend libraries
congrats on learning some new tools! it is a bit 'astronaut architected' but you seem to have a history of building stuff and asking for feedback, that will always result in learning fast. hope you got some useful replies here!

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

unless we all got click baited > https://dev.to/nevodavid Technical Content Writing + DISTRIBUTION
That's my other business :) Clickvote is mine also, and I am very serious about it.
I’d love this for slack
Can't you just use certain reactions for voting in Slack?