161–170 of 232 posts
Earlier quoted context omitted.
No longer the BDFL, unfortunately.
The BDFL is a position that you have for life. It is embedded in the definition. So it is impossible to shed the title.
Based on the top comments in this thread, I can see my previous attempts to dispel mistaken beliefs around graphql have failed, but I'll still try! 1. The biggest mistake GraphQL made was putting 'QL' in the name so people think it's a query language comparable to SQL. It's not: https://news.ycombinator.com/item?id=23120997 2. Some benefits of GraphQL over REST: https://news.ycombinator.com/item?id=23124862
I firmly believe GraphQL is a fad. It will never work, exposing the ORM to your clients. I'm curious, why don't we see more public-facing APIs using gRPC?
One thing I've noticed is it seems redux and graphql are solving the same problem in an entirely different way
Tbh I'd expected a little better than framing this question in a "REST vs GraphQL" discussion coming from sourcehut.org. If you control your backend, you can aggregate whatever payloads you please into a single HTTP response, and don't have to subscribe to a (naive) "RESTful" way where you have network roundtrips for every single "resource", a practice criticized by Roy Fielding (who coined the term "REST") himself a…
If you don't like REST, don't use it. Whatever you do, don't even think that GraphQL will solve your problems. You were on the right track staying away from it till now. I can't also advise enough to stay away from a typed language (Go in this case) serving data in a different typed language (gql). You will eventually be pulling your hair out jumping through hoops matching types. After my last web project that requir…
Earlier quoted context omitted.
As for the reason to use Go instead of Rust it is probably just down to the creator of Sourcehut he has multiple times expressed that he dislikes rust quite a bit. He has written a blog post about how he chooses programming languages as well https://drewdevault.com/2019/09/08/Enough-to-decide.html
It's the first time I hear that haskell has awful package management...
Earlier quoted context omitted.
What would be the advantage of GraphQL over gRPC in a REST replacement scenario?
I'm only passingly familiar with gRPC, so forgive me if it offers some kind of linking like what I describe below. In REST (and seemingly in gRPC), you define these siloed endpoints to return different types of data. If we're imagining a Twitter REST API, you might imagine Tweet and User endpoints. In the beginning it's simple - the Tweet endpoint returns the message, the user ID, and some metadata. You can query the…
The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features. Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a…
I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you) It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs. ORM suffer from being at beyond arms length from the query analyzer in the database server. https://en.wikipedia.org/w…
I don't see the conflict? If the GraphQL query is translated into SQL on the server, then then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally.
A decent system will provide the hooks you need to hand optimize certain cases somehow, but There are always limitations and hoops to jump through and additional complexity to manage. The extra layers that are meant to make your life easier are getting in the way instead. (May or may not still be worth it, but the point is, it’s not a foregone conclusion.)
Earlier quoted context omitted.
My worry with GraphQL is that the server component is essentially a black box (as I don't have time to audit/review it) complex enough that there's more chance an edge case in a GraphQL query will end up exposing something you don't want. A REST endpoint on the other hand is fairly simple and understood; there's (mostly) a static set SQL queries behind it and as long as those are not returning any unwanted data you a…
the graphql server has a contract (the schema) that it will follow, or 500. So you know what you get back is exactly to spec. Or you get nothing. REST endpoints are usually way more blackbox. You can't claim that REST is better cuz you can look at the server... when you could do the same thing to the graphql server. Graphql will -never- return you unwanted data. Because you wrote in the query exactly what you want. I…
But couldn't you intentionally or unintentionally write a query such that it returns too much data and borks the system? Un-intentionally is the worrisome aspect.