10 ms·

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so

by thdxr 4y ago

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache normalization. If you look at clients like URQL they enable high quality features in your app that are otherwise extremely difficult. You can also do this with JSONAPI but the GraphQL ecosystem is more developed. Setting up GraphQL to minimize its rough edges is incredibly difficult. I've currently landed on a combination of Pothos + Genql + URQL to enable me to do everything in typescript instead of untyped strings. It takes very high skill to use GraphQL well. Few teams get there because they don't have the upfront time to do all the research. But if you pull it off it can be an incredibly productive system that is friendly to iteration and refactoring. I can send you some content we've produced on this if you're interested. That said, if I'm not working on a client heavy app, I'd just use a less featureful RPC framework.

chpmrc 4y ago
> Be careful with anyone with a take that says some technology is 100% bad always. THIS 100%. > It takes very high skill to use GraphQL well. But if you pull it off it can be an incredibly productive system that is friendly to integration and refactoring. I could not agree more. It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. And then it's hard to imagine going back to something more "primitive" (i.e. what's conventionally called "REST"). After building "RESTful" APIs for years I can confidently say GraphQL (with a decent implementation) is a step up across almost every possible dimension (performance aside because of the additional parsing).
- throwawaymaths 4y ago
  Eh I think "rest for external API access, graphql for internal frontend use" is probably a good thing.
- necovek 4y ago
  > It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. While this is true, I think the ultimate assesment of a technology is how easy is it for someone skilled at doing similar work to internalize the model and abstractions. A tech stack can become really successful only if this is easy and relatively quick, otherwise, it will meet a lot of resistance. Partly because it's hard to master, but partly because so many people will be misusing it (which makes an even bigger annoyance for someone who's trying to get to a proper mental model). As such, I've come to appreciate only models that majority of developers can easily get right on the first go: or rather, models which are hard to get wrong.
mccorrinall 4y ago
I love consuming graphql as a client. But writing resolvers and all that stuff on the backend? God, I hate it!
- nawgz 4y ago
  Hasura :)
  - ant1oz 4y ago
    Have you every tried to version your permissions on Hasura? Not cool. Product polish is amazing, and I love the postgresql integration.
    - cpursley 4y ago
      Interesting point. What sort of approaches out there do you know about for versioning permissions?
    - nawgz 4y ago
      Nope, I haven't, here's hoping I won't need to! First time thinking about the situation, sounds to me like you'd need to just make a new set of roles no? I can't imagine they'd have version support for that, not like the underlying datastore does
- adra 4y ago
  I don't know your language of choice, but in the JVM ecosystem, Netflix DGS is so damn simple to build new resolvers.
- kubami 4y ago
  It's very enjoyable with python. Especially given integrations with frameworks like django.
endisneigh 4y ago
> Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worse from people giving things a fair try. Completely agreed. Without knowing the team experience, greenfield project or not or in general more information about the task at hand, how can anyone say GraphQL is good or not? One thing I've noticed among some people who've failed to move up in their career is that they carry these extreme opinions due to a proper understanding or a bad experience. Right tool for the job and all that.
meesterdude 4y ago
> Given enough experience / skill you can make any technology fairly enjoyable Have you never used MongoDB?
- thdxr 4y ago
  https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo7AoXv9OhYJB06wqBA&s=19 https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo...
  - Kaze404 4y ago
    That’s a great thread. It mimics my (admittedly limited) experience with MongoDB and it’s interesting to hear that wasn’t an outlier.
  - mdaniel 4y ago
    https://threadreaderapp.com/thread/1394903426023272452.html https://threadreaderapp.com/thread/1394903426023272452.html
  - mst 4y ago
    The other thing to note is that early on the default configuration was optimised to score really well on trivial benchmarks rather than production workloads - including having important safety features turned off. A crashing MongoDB instance in default configuration was more likely to lose data irrevocably than a MySQL 3.23 MyISAM setup. (note that while I still don't particularly enjoy using it, post-WiredTiger MongoDB is a different story so take this as a criticism of the people making choices in the early days, not at all of the current state of affairs)
lf-non 4y ago
Agree with everything here, but something that often gets missed is that you don't have to use all that GraphQL enables from day one. It is perfectly fine to start with an early implementation that treats GraphQL as mostly an RPC, with only resolvers for Query & Mutation types. You still benefit from GraphQL's type-safety, batching and code-generation. Once you have more familiarity with dataloaders, query complexity etc. update your output objects to have links to other output objects building the graph model. The issue is that too many people get fascinated with GraphQL early, then build deep & complex topologies and expose it in inefficient and potentially insecure way.
deltasevennine 4y ago
>Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. So what does this mean? You're saying that in the universe we live in there is absolutely nothing that is 100% bad always. Everything is good for something? There is no concept of bad or obsolete things because it's all good for something? Let's restrict this to programming languages and frameworks and apis. Are you saying that in the universe of ALL programming languages, ALL frameworks and all APIs, None of them are at all bad and they are all good for something? I don't agree with this sentiment at all. In fact I think it's a sign of two possibilities: 1. that the person saying it is highly biased and unable to detect things that are genuinely bad. 2. The person saying it is just being temporarily illogical, there are clearly things in the programming world that are bad. He knows this but is so biased that he's incapable of processing this concept while promoting his favorite language/api/framework. Scenario 2 is the most likely scenario here. Not saying graphQL is bad. But to love graphQL so much as to say Nothing in the universe is actually bad? Let's be real, I am not against graphQL. However you cannot actually say that people against graphQL have invalid opinions because there is nothing in the programming universe that is definitively bad. This argument does not make any sense at all.
- Kaze404 4y ago
  The point is that “bad” isn’t a useful descriptor of anything regarding their real-life applications, because it simply doesn’t mean anything. Without more context, saying something is bad is just saying you dislike it with intent to present it as objective rather than subjective. For example: 1) “Haskell is bad because it’s too theoretical” 2) “Haskell is bad in corporate environments, as its roots in mathematical and academia make it harder for people to get productive with it compared to something like Java or C#” The difference is clear. In my opinion it’s best if people who care about what they’re saying avoids #1, and instead frames their criticism like in #2. Note: those examples don’t reflect my actual opinion on Haskell, it’s just something I came up with while writing this.
  - deltasevennine 4y ago
eduction 4y ago
> Be careful with anyone with a take that says some technology is 100% bad always. This isn’t that though; the first sentence starts “GraphQL is great, but” and then the post lists first “the good” and then “the bad.” Even the provocative headline hedges with “kinda.” I wish there was more of this sort of balanced discussion on HN. There is a tendency among devs at least in public toward trying to get others to use the tech they use and are excited about, which is understandable, but everything involves trade offs and it would be nice to hear more of those up front (as opposed to one day “mongo is the bomb” and the next “actually mongo is terrible to back to postgres for everything).
- thdxr 4y ago
  was referring to some of the replies
  - eduction 4y ago
    Ah ok I definitely misunderstood, thanks for clarifying.
- minusf 4y ago
  > balanced discussion while the discussion can be balanced the real world outcome is normally binary: use it or drop it. i will not start investing huge amounts of time to learn graphql if it has very specific use cases for specific environments. so i naturally look for red flags and objectively negative experiences to see if those might be the roadblocks i would run into 2 months down the line. imagine a PM coming in all happy "i know nothing about graphql besides the hype but i think it's a great fit for our next project". where will balanced discussion take you there?
PainfullyNormal 4y ago
> Be careful with anyone with a take that says some technology is 100% bad always. On the flip side, you should also be careful of anyone who says some technology is 100% good always. It's far more common to see people talking up the advantages of some trendy new technology without ever mentioning the downsides. All technologies have tradeoffs.

by thdxr 4y ago

chpmrc 4y ago

> Be careful with anyone with a take that says some technology is 100% bad always. THIS 100%. > It takes very high skill to use GraphQL well. But if you pull it off it can be an incredibly productive system that is friendly to integration and refactoring. I could not agree more. It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. And then it's hard to imagine going back to something more "primitive" (i.e. what's conventionally called "REST"). After building "RESTful" APIs for years I can confidently say GraphQL (with a decent implementation) is a step up across almost every possible dimension (performance aside because of the additional parsing).

throwawaymaths 4y ago
Eh I think "rest for external API access, graphql for internal frontend use" is probably a good thing.
necovek 4y ago
> It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. While this is true, I think the ultimate assesment of a technology is how easy is it for someone skilled at doing similar work to internalize the model and abstractions. A tech stack can become really successful only if this is easy and relatively quick, otherwise, it will meet a lot of resistance. Partly because it's hard to master, but partly because so many people will be misusing it (which makes an even bigger annoyance for someone who's trying to get to a proper mental model). As such, I've come to appreciate only models that majority of developers can easily get right on the first go: or rather, models which are hard to get wrong.

mccorrinall 4y ago

I love consuming graphql as a client. But writing resolvers and all that stuff on the backend? God, I hate it!

nawgz 4y ago
Hasura :)
- ant1oz 4y ago
  Have you every tried to version your permissions on Hasura? Not cool. Product polish is amazing, and I love the postgresql integration.
  - cpursley 4y ago
    Interesting point. What sort of approaches out there do you know about for versioning permissions?
  - nawgz 4y ago
    Nope, I haven't, here's hoping I won't need to! First time thinking about the situation, sounds to me like you'd need to just make a new set of roles no? I can't imagine they'd have version support for that, not like the underlying datastore does
adra 4y ago
I don't know your language of choice, but in the JVM ecosystem, Netflix DGS is so damn simple to build new resolvers.
kubami 4y ago
It's very enjoyable with python. Especially given integrations with frameworks like django.

endisneigh 4y ago

> Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worse from people giving things a fair try. Completely agreed. Without knowing the team experience, greenfield project or not or in general more information about the task at hand, how can anyone say GraphQL is good or not? One thing I've noticed among some people who've failed to move up in their career is that they carry these extreme opinions due to a proper understanding or a bad experience. Right tool for the job and all that.

meesterdude 4y ago

> Given enough experience / skill you can make any technology fairly enjoyable Have you never used MongoDB?

thdxr 4y ago
https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo7AoXv9OhYJB06wqBA&s=19 https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo...
- Kaze404 4y ago
  That’s a great thread. It mimics my (admittedly limited) experience with MongoDB and it’s interesting to hear that wasn’t an outlier.
- mdaniel 4y ago
  https://threadreaderapp.com/thread/1394903426023272452.html https://threadreaderapp.com/thread/1394903426023272452.html
- mst 4y ago
  The other thing to note is that early on the default configuration was optimised to score really well on trivial benchmarks rather than production workloads - including having important safety features turned off. A crashing MongoDB instance in default configuration was more likely to lose data irrevocably than a MySQL 3.23 MyISAM setup. (note that while I still don't particularly enjoy using it, post-WiredTiger MongoDB is a different story so take this as a criticism of the people making choices in the early days, not at all of the current state of affairs)

lf-non 4y ago

Agree with everything here, but something that often gets missed is that you don't have to use all that GraphQL enables from day one. It is perfectly fine to start with an early implementation that treats GraphQL as mostly an RPC, with only resolvers for Query & Mutation types. You still benefit from GraphQL's type-safety, batching and code-generation. Once you have more familiarity with dataloaders, query complexity etc. update your output objects to have links to other output objects building the graph model. The issue is that too many people get fascinated with GraphQL early, then build deep & complex topologies and expose it in inefficient and potentially insecure way.

deltasevennine 4y ago

>Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. So what does this mean? You're saying that in the universe we live in there is absolutely nothing that is 100% bad always. Everything is good for something? There is no concept of bad or obsolete things because it's all good for something? Let's restrict this to programming languages and frameworks and apis. Are you saying that in the universe of ALL programming languages, ALL frameworks and all APIs, None of them are at all bad and they are all good for something? I don't agree with this sentiment at all. In fact I think it's a sign of two possibilities: 1. that the person saying it is highly biased and unable to detect things that are genuinely bad. 2. The person saying it is just being temporarily illogical, there are clearly things in the programming world that are bad. He knows this but is so biased that he's incapable of processing this concept while promoting his favorite language/api/framework. Scenario 2 is the most likely scenario here. Not saying graphQL is bad. But to love graphQL so much as to say Nothing in the universe is actually bad? Let's be real, I am not against graphQL. However you cannot actually say that people against graphQL have invalid opinions because there is nothing in the programming universe that is definitively bad. This argument does not make any sense at all.

Kaze404 4y ago
The point is that “bad” isn’t a useful descriptor of anything regarding their real-life applications, because it simply doesn’t mean anything. Without more context, saying something is bad is just saying you dislike it with intent to present it as objective rather than subjective. For example: 1) “Haskell is bad because it’s too theoretical” 2) “Haskell is bad in corporate environments, as its roots in mathematical and academia make it harder for people to get productive with it compared to something like Java or C#” The difference is clear. In my opinion it’s best if people who care about what they’re saying avoids #1, and instead frames their criticism like in #2. Note: those examples don’t reflect my actual opinion on Haskell, it’s just something I came up with while writing this.
- deltasevennine 4y ago

eduction 4y ago

> Be careful with anyone with a take that says some technology is 100% bad always. This isn’t that though; the first sentence starts “GraphQL is great, but” and then the post lists first “the good” and then “the bad.” Even the provocative headline hedges with “kinda.” I wish there was more of this sort of balanced discussion on HN. There is a tendency among devs at least in public toward trying to get others to use the tech they use and are excited about, which is understandable, but everything involves trade offs and it would be nice to hear more of those up front (as opposed to one day “mongo is the bomb” and the next “actually mongo is terrible to back to postgres for everything).

thdxr 4y ago
was referring to some of the replies
- eduction 4y ago
  Ah ok I definitely misunderstood, thanks for clarifying.
minusf 4y ago
> balanced discussion while the discussion can be balanced the real world outcome is normally binary: use it or drop it. i will not start investing huge amounts of time to learn graphql if it has very specific use cases for specific environments. so i naturally look for red flags and objectively negative experiences to see if those might be the roadblocks i would run into 2 months down the line. imagine a PM coming in all happy "i know nothing about graphql besides the hype but i think it's a great fit for our next project". where will balanced discussion take you there?

PainfullyNormal 4y ago

> Be careful with anyone with a take that says some technology is 100% bad always. On the flip side, you should also be careful of anyone who says some technology is 100% good always. It's far more common to see people talking up the advantages of some trendy new technology without ever mentioning the downsides. All technologies have tradeoffs.