[HN Gopher] Show HN: Clickvote - Open-source upvotes, likes, and...
___________________________________________________________________
Show HN: Clickvote - Open-source upvotes, likes, and reviews to any
context
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?
Author : nevodavid10
Score : 104 points
Date : 2023-07-11 14:29 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bandrami wrote:
| So, Digg?
| nevodavid10 wrote:
| Digggg
| dcsan wrote:
| 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
| dcsan wrote:
| unless we all got click baited > https://dev.to/nevodavid
| Technical Content Writing + DISTRIBUTION
| tomcam wrote:
| 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.
| noam_compsci wrote:
| I'd love this for slack
| kodah wrote:
| Can't you just use certain reactions for voting in Slack?
| bastawhiz wrote:
| 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.
| klysm wrote:
| 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.
| astura wrote:
| Resume Driven Development.
| nefarious_ends wrote:
| oh wow this is a term I've been looking for for ages!
| shri_krishna wrote:
| Even better is to just use Clickhouse (maybe Kafka if there are
| lots of inserts and async_insert isn't sufficient) and
| Postgres.
| nevodavid10 wrote:
| 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.
| bee_rider wrote:
| 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...
| badtuple wrote:
| 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.
| bastawhiz wrote:
| 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.
| upon_drumhead wrote:
| 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?
| ransom1538 wrote:
| [flagged]
| wizzwizz4 wrote:
| Some tools are good for some jobs. Other tools are good for
| other jobs. There's no "war".
| bastawhiz wrote:
| 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?
| pjot wrote:
| pg_dump --schema-only --table=tablename databasename
| renewiltord wrote:
| 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.
| _a9 wrote:
| 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.
| worksonmine wrote:
| Up- and downvotes without authentication will be abused.
| izktj wrote:
| 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
| nevodavid10 wrote:
| Maybe give it another go?
| linuxdude314 wrote:
| 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.
| nevodavid10 wrote:
| I got everything that you said! I might change it to be a bit
| simpler
|
| https://media.discordapp.net/attachments/1062038639112097872...
|
| Happy to get some feedback on the product also :)
| gerimate wrote:
| I can see it being very useful for early-stage products and A/B
| testing, so keep going, congrats!
| nevodavid10 wrote:
| Thank you so much Happy to hear about A/B testing idea!
| wentin wrote:
| You should put React library to your title, it makes it easier
| for potential users.
| nevodavid10 wrote:
| It should over time support all frontend libraries
| tomas789 wrote:
| 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.
| bastawhiz wrote:
| 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.
| nevodavid10 wrote:
| Can you elaborate on this? ^_^
| rglullis wrote:
| 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.
| that_guy_iain wrote:
| 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.
| nevodavid10 wrote:
| In my weird dream, people will attach likes to everything :)
| jitl wrote:
| 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.
| nevodavid10 wrote:
| I am failing to understand your question insert into
| user_rating will work. This is what it's doing now?
| halfmatthalfcat wrote:
| 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.
| nevodavid10 wrote:
| 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.
| jitl wrote:
| 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.
| bastawhiz wrote:
| > 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).
| nevodavid10 wrote:
| It's not a big problem to create another version without
| Kafka, and use Postgres :)
|
| What do you think about the idea?
| bastawhiz wrote:
| 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.
| nevodavid10 wrote:
| https://github.com/clickvote/clickvote/blob/main/libs/nest-l...
|
| And yes - Twitter for example?
| DandyDev wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-11 23:01 UTC)