5 ms·

OpenAPI and client generators solve this issue easily.

by phito 11mo ago

robertlagrant 11mo ago
No, that's not true. If you share code like this then you can do things like put the same validation code in the frontend and the backend: frontend to give a nice user experience, and backend to protect the endpoint.
- littlecranky67 11mo ago
  OpenAPI does support patterns for fields and nullables/non-nullables - that already gets you very far regarding validation. A decently sophisticated generator (which don't exist IMHO) would generate the validation code for your respective language.
  - robertlagrant 11mo ago
    True, but you can get all the way to zero duplication if you write it directly and share that code.
    - deleted 11mo ago
      [deleted]
cies 11mo ago
Or GraphQL. Still one lang on both ends is nice: there are some bits of code you want to run on both ends (like templating for SSR/SEO/caching; but also using them in the browser).
josephg 11mo ago
Still more work than just running the same code everywhere.
- phito 11mo ago
  Still better than bringing JavaScript to the back end shudders
littlecranky67 11mo ago
I would love this to be true, but it isn't. I've done generating types for the frontend multiple times, sometimes from C# (around 2016, using typelite), Java (openapi template generator) and most recently straight from OpenAPI spec files (.yaml) using Orval. It always has been a shitshow. It works well for the 90% cases, but in the 10% edge cases, things break. It becomes impossible to fix generation issues, you will often resort in working around issues in your backend/openapi code. Sometimes you report bugs upstream and hope it gets fixed. In the current project we are stuck on a ~2year old Orval version (a typescript generator from openapi) because some features broke or were removed in the latest version, and the entire monorepo (15+ LoB apps) wouldn't compile and would require major changes. This simply because a never version of the generator was broken/removed features previously present.

OpenAPI and client generators solve this issue easily.

by phito 11mo ago

OpenAPI and client generators solve this issue easily.

No, that's not true. If you share code like this then you can do things like put the same validation code in the frontend and the backend: frontend to give a nice user experience, and backend to protect the endpoint.

littlecranky67 11mo ago
OpenAPI does support patterns for fields and nullables/non-nullables - that already gets you very far regarding validation. A decently sophisticated generator (which don't exist IMHO) would generate the validation code for your respective language.
- robertlagrant 11mo ago
  True, but you can get all the way to zero duplication if you write it directly and share that code.
  - deleted 11mo ago
    [deleted]

cies 11mo ago

Or GraphQL. Still one lang on both ends is nice: there are some bits of code you want to run on both ends (like templating for SSR/SEO/caching; but also using them in the browser).

josephg 11mo ago

Still more work than just running the same code everywhere.

phito 11mo ago
Still better than bringing JavaScript to the back end shudders

littlecranky67 11mo ago

I would love this to be true, but it isn't. I've done generating types for the frontend multiple times, sometimes from C# (around 2016, using typelite), Java (openapi template generator) and most recently straight from OpenAPI spec files (.yaml) using Orval. It always has been a shitshow. It works well for the 90% cases, but in the 10% edge cases, things break. It becomes impossible to fix generation issues, you will often resort in working around issues in your backend/openapi code. Sometimes you report bugs upstream and hope it gets fixed. In the current project we are stuck on a ~2year old Orval version (a typescript generator from openapi) because some features broke or were removed in the latest version, and the entire monorepo (15+ LoB apps) wouldn't compile and would require major changes. This simply because a never version of the generator was broken/removed features previously present.