jelan
Joined 4 years ago
Joined 4 years ago
Product Hunt tries their best to detect when bots are upvoting, and responds by removing those upvotes (you can see this happen on many hunts by looking at the upvote rate graph, if it takes a sharp almost impulse like decline that usually means PH is removing upvotes based on some kind of fraud protection they have)
I’m not sure why people still feel the need to cheat to get to number one on PH, it really doesn’t mean anything close to what it once did. Speaking from personal experience, a startup company I used to work for put great time and effort into their debut on PH, ended up in the top spot for the day, and got exactly 0 press, 0 new registrations that didn’t instantly churn, and 0 feedback on the product that was actually worthwhile. The only thing we did get on a daily basis was, you guessed it, emails from people also launching on PH asking for upvotes!
Significant engineering time will need to be spent ironing out important things that just work with REST (like caching).
The best analogy I have for what working with GraphQL on the backend is like is the “If you give a mouse a cookie” story [1].
You try to set up an API but end up being asked to implement three different caching layers, using the data loader pattern to batch requests to the DB to improve performance, discovering that custom error handling code is needed to get non 200 status codes back from your API, using persisted queries now that your frontend is asking for a lot of data in the body of the request which is taking up too much bandwidth, etc…
The code as you can imagine after doing all this is very hard to follow, even without doing any of the optimizations I listed above there are things like reference resolvers that make tracking down bugs or just finding where the data is being collected from a nightmare.
[1]: https://en.m.wikipedia.org/wiki/If_You_Give_a_Mouse_a_Cookie
Thanks for your input on this, I know you said you are an SRE manager but assuming you were once an SRE yourself, did you enjoy that line of work?
I know we can’t just pause the internet while everyone comes to a consensus on how we want to make it more interactive and fix underlying problems, but at least to me it seems like all the effort that could be spent working towards that is instead being spent figuring out ways to just avoid as much of the underlying pieces as possible by jamming your own implementation on top of it.
I agree that getting setup and using things like React or Node for a backend is easy, but the number of dependencies, size of the app, tooling needed, memory used are all going to grow exponentially as soon as you start trying to do something non trivial, and the solution to fix these problems is yet again to add more complexity, where you will need to learn a lot more about how all of those nice tools that just worked for you out of the box are actually working
This isn’t a React or a frontend specific example entirely, but I’ve seen many people jump into creating a simple app and right off the bat implementing a federated GraphQL design because of all the great things they heard about GraphQL from the community, which is fine but a very simple REST design would have worked just as well if not better and would be in my opinion much simpler to maintain and manage complex things like caching.
Does it do any kind of sound identification or matching? So if I sneeze around the device around the same time another system picks up a firework sound, will it be able to figure that out or is that a post process thing?
Would be interesting for you and your friends to pick a very exact point on GPS somewhere in the middle of all you and light off a big firework, then go back and see how close the system thought it was to the actual location. I know that kind of defeats the purpose of not launching illegal fireworks, but it’s better than shooting a gun in the air I guess.