• MajorHavoc@programming.dev
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    edit-2
    7 months ago

    Oh, sure.

    Primaly, it was needlessly complicated.

    I read through a rabbit trail of (unconvincing) documents saying “here’s why the way that has worked for decades for you isn’t good enough anymore” leading to “and that’s why we decided not to implement this quality of life feature you have learned to expect”.

    It had a “only fit for the truly faithful” cult vibe, last time I checked it, which was about a year ago.

    The big thing that turned me off was I did not find a lack of tooling to auto-generate an HTML page that helps explore the API. It seems to me that it would be easier to do so when using strong types, not harder.

    Edit 3: I never found: https://docs.github.com/en/graphql/overview/explorer I swear I really did look for it. Pinky promise.

    Edit: And since I’m already in brutal honestly mode, the GraphQL docs read, to me, as being by someone who didn’t really deeply understand the HTTP specification, or at least couldn’t really articulate why they needed a new tool that used less (as far as I could tell from the docs) of that specification, than existing tools.

    Betting against hugely popular protocols sometimes, very rarely, pays off. But GraphQL is already well on the way to being forgotten. I don’t expect GraphQL to reach a tool maturity level that causes me to ever take a second look.

    Edit: For context, I once bet against git. So what the hell do I know. We shall see!

    • deadbeef79000@lemmy.nz
      link
      fedilink
      arrow-up
      7
      ·
      7 months ago

      …by someone who didn’t really deeply understand the HTTP specification, or at least couldn’t really articulate why they needed a new tool that used less…

      Thousand yard stare at SOAP

      Yo dawg, I heard you like XML over HTTP so I put XML in HTTP in your XML over HTTP.

      So many technologies doing crap that plain old HTTP already does:

      • name a resource: URL
      • discover verbs for a resource: OPTIONS
      • execute a verb: the actual request
      • define a response type: Headers
      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        Thousand yard stare at SOAP

        Yo dawg, I heard you like XML over HTTP so I put XML in HTTP in your XML over HTTP.

        Made me spit my drink, laughing. Thank you. Very true.

      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        edit-2
        7 months ago

        Thank all that is holy, I did not use it. I had other options, which I chose, because I’m the boss.

        Edit: I’m not proud of my occasional tendency to wind y’all up for fun, but I will say it helps proactively build my block list of folks who can’t take a joke.

        • FizzyOrange@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          7 months ago

          The experience was awful.

          I did not use it.

          Hmm. You sure have a strong hatred of a thing you never used, about which your main objection (no HTML explorer) is completely untrue.

          I don’t think anyone would say you need GraphQL for a tiny 10-20 endpoint project. It’s for big projects.

    • trolololol@lemmy.world
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      7 months ago

      If Json wasn’t status quo, coming from a language that’s status quo, all these comments could be reversed against it.

      And well, if you’re not using JavaScript, Json is not that great anyways.

      What I like about graphql that Json over rest doesn’t have it: fragments and types.

      On types: have you ever got across bad swagger documentation? Like a parameter called something unclear like usertype, with no explanation of what it is or examples, ? Oh yeah, it’s a string. Very helpful. Well in graph ql, that parameter is likely to be called userType, which if you go into the schema file, you’ll likely see it’s an enum and you’ll also see all possible values. If your backend developer is half decent you’ll also get comments right there next to the enum. You don’t need a tool to spit out a html page that you’ll host somewher. Most reasonable information can be part of the schema file, and that’s it.

      All that said, everyone now is familiar with Json and rest. Because of that, small projects are better doing it. But that supremacy will eventually end. And for large projects, specially with static types, graphql makes some things much easier, like types, fragments and unions.