Not sure how this got into onto HN. Maybe hackandthink can explain.
This product does not actually exist. I wanted to see if there was demand for something like this so I created a landing page for it a few years ago. It only got bad responses. Mostly worries about how authorization rules would work and that it could never be done securely, so I never ended up building it, even though I didn't fully agree with that concern.
So I am the first who likes your idea. I just stumbled over it when doing some research. (I think SQL and React Server Components will go together nicely)
You've airbnb, coinbase, instgram, dribble, pintrest, and netflix listed there. There are no case studies or documentation about them and these logos themselves aren't clickable.
How are these companies using this technology? Are they using it in prod? Is it in one of their main apps or just an internal tool?
What happens at scale? How do I separate read and write pools? How can I tune query configs and wait times?
As soon as I saw the brand logos I was instantly turned off. It's still in "beta" and yet it already has some of the biggest brands using it? Bullshit. Whenever I see these non clickable brand logos on a SaaS product I instantly assume it's a dishonest lying grifter. I can only urge people to stay honest, you don't need this bs to fill your landing page. Just add an extra section which shows me how your product solves a cool problem rather than some logos of fake customers.
It was based on a template. I thought it was harmless. I just wanted to get a good idea of how much demand there would be so I made it look as good as I could. My apologies.
The screenshot looks like a copy of the hasura web console. The same looks also similar to Hasura’s internal RQL. I wonder if this is just a coincidence.
this completes the move from the server side to the client side
yes, it looks a little crazy and there are certainly serious security considerations (they support ACLs it looks like) but this is the logical end point of JavaScript-based applications that jettison the hypermedia infrastructure of the web
REST (so called, see[1]) was the first step, GraphQL the second step and now this completes the move of pushing the expressiveness found on the server side over to the client side.
this comment further confirms my belief that GraphQL is a cult.
> this completes the move from the server side to the client side
OK, how does that benefit end users, developers, or administrators? I have never had a person approach me to make a website with a client side database.
> REST (so called, see[1]) was the first step, GraphQL the second step and now this completes the move of pushing the expressiveness found on the server side over to the client side.
Again, I don't see the point..? Who does this benefit..? Front-end only devs who want think doing everything on the front end makes a website more modern/app-like..?
Web architectures aren't separated in front end/back end because of technological limitations. We could've been running databases in the browser for decades now. We don't because of Separation of Concerns...
The front end is for presentation tier logic.. the backend is for business logic.
Just because you can do something doesn't mean you _should_, and when something has been possible for a long time but hasn't been done very often, you should ask yourself why that is.
Not sure how this got into onto HN. Maybe hackandthink can explain.
This product does not actually exist. I wanted to see if there was demand for something like this so I created a landing page for it a few years ago. It only got bad responses. Mostly worries about how authorization rules would work and that it could never be done securely, so I never ended up building it, even though I didn't fully agree with that concern.
I should probably take the page down.