Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
11–20 of 59 posts
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#12I love how in the age of good old PHP, Django and alike this would be insanity. But with serverless it makes sense I guess.
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#13Earlier quoted context omitted.
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.
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).
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#14I love how in the age of good old PHP, Django and alike this would be insanity. But with serverless it makes sense I guess.
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#15Why 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 co…
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#16Earlier quoted context omitted.
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 av…
What do you think about the idea?
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#17Earlier quoted context omitted.
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.
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.
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#18Why 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 co…
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.
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…
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#19Why 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 co…
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.
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.
Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context
#20I 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 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.