3 ms·

Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like th

by diggan 1y ago

Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.

koakuma-chan 1y ago
> Personally I'd chose Clojure for anything I have a choice with. And then you would have to solve the problem of how to communicate with the client.
- diggan 1y ago
  I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?
  - koakuma-chan 1y ago
    > Not sure why you'd think that be a difficult thing? You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.
    - diggan 1y ago
      What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.
      - koakuma-chan 1y ago
        > What exactly is the problem you're encountering when trying to interact with HTTP APIs? The problem is that, unlike when using server actions, when using HTTP APIs, there is nothing that automatically generates bindings. > If you really want to use OpenAPI for whatever reason No, I don't. But people use OpenAPI to avoid having to handwrite an HTTP client. This is especially relevant if you are developing a public API. > But it's not like using OpenAPI or GraphQL are the only two options What are other options?
        floydnoel 1y ago
        "handwriting" an HTTP client is too much work for a developer? you need to import a library that does it for you? wow. abstraction at any cost, eh?
        koakuma-chan 1y ago
        Yes, you have to waste time handwriting it and making sure that you actually wrote a proper binding. Then you also probably need to deal with API versioning. All of this goes away with server actions.
        diggan 1y ago
        > when using HTTP APIs, there is nothing that automatically generates bindings. Is that really the biggest problem you face when programming? How many endpoints do you have? Even with projects with ~30 endpoints, it doesn't seem problematic to me, but maybe people regularly work on projects with 100s of endpoints, then it kind of makes sense. But I'm not sure that's typical enough. > No, I don't. But people use OpenAPI to avoid having to handwrite an HTTP client. This is especially relevant if you are developing a public API. People do a lot of stuff for a lot of nonsense reasons, doesn't mean that's the best way to approach things. The JS/TS ecosystem seems extra easy to fall into cargo culting too.

by diggan 1y ago

Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.

koakuma-chan 1y ago

> Personally I'd chose Clojure for anything I have a choice with. And then you would have to solve the problem of how to communicate with the client.

diggan 1y ago
I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?
- koakuma-chan 1y ago
  > Not sure why you'd think that be a difficult thing? You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.
  - diggan 1y ago
    What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.
    - koakuma-chan 1y ago
      > What exactly is the problem you're encountering when trying to interact with HTTP APIs? The problem is that, unlike when using server actions, when using HTTP APIs, there is nothing that automatically generates bindings. > If you really want to use OpenAPI for whatever reason No, I don't. But people use OpenAPI to avoid having to handwrite an HTTP client. This is especially relevant if you are developing a public API. > But it's not like using OpenAPI or GraphQL are the only two options What are other options?
      - floydnoel 1y ago
        "handwriting" an HTTP client is too much work for a developer? you need to import a library that does it for you? wow. abstraction at any cost, eh?
        koakuma-chan 1y ago
        Yes, you have to waste time handwriting it and making sure that you actually wrote a proper binding. Then you also probably need to deal with API versioning. All of this goes away with server actions.
      - diggan 1y ago
        > when using HTTP APIs, there is nothing that automatically generates bindings. Is that really the biggest problem you face when programming? How many endpoints do you have? Even with projects with ~30 endpoints, it doesn't seem problematic to me, but maybe people regularly work on projects with 100s of endpoints, then it kind of makes sense. But I'm not sure that's typical enough. > No, I don't. But people use OpenAPI to avoid having to handwrite an HTTP client. This is especially relevant if you are developing a public API. People do a lot of stuff for a lot of nonsense reasons, doesn't mean that's the best way to approach things. The JS/TS ecosystem seems extra easy to fall into cargo culting too.