@samir I definitely share the love for darklang-classic💜

I find it sad, that they turned their back on their editor. I don’t quite understand where they are now going with darklang, but this broke my programmer heart a little:

From https://blog.darklang.com/gpt/

“…a non-freeform editing experience that our users have rated somewhere between "Ok I guess" and "probably the worst part of Darklang”

😭

@samir thanks for writing this down. I think in some regards this is what we have been doing at bryter.com, however as a closed platform…

I can recommend googling for “projectional editing”. There are a couple of fun things out there. One of the interesting experiments is https://www.lamdu.org.

See also https://github.com/yairchu/awesome-structure-editors

@coderbyheart we could generate the paths from hapijs router, however the chance of a route being wrong is usually small.

Wrt. testing I had tried some things in the past https://dredd.org with Swagger, the Postman runner before Postman turned bad and one more method I can’t remember.

At the end of the day, E2E tests often need too much glue code, like navigating, templating or generating random data to avoid conflicts. Also the API behavior is imo more interesting than the structure.

@coderbyheart I would always suggest to generate the spec from the code if you can. If you do this, there should be no need to validate the spec using tests.

FWIW we use https://zod.dev to write our API input and output validations and then use the zod schemas to generate the OpenAPI schemas. The spec is rendered to documentation at https://developers.enode.com/api/reference#introduction. We still maintain the routes manunally, but that way at least the data structures are correctly typed.

@ascheman ich war mit meinen ersten Schätzungen arg daneben, aber mein Bild sieht gleich aus 😅

#pastpuzzle 43
🟩🟩🟥🟥 (-33)
🟩🟩🟥🟥 (-21)
🟩🟩🟩🟥 (+3)
🟩🟩🟩🟩 (0)

4/4 🟩
https://www.pastpuzzle.de