2 ms·
After years of programming against REST(ish) APIs backed by statically typed languages, I'm now fighting one built by a team that loves ruby/rails. It's a terr
by zdragnar 2y ago
After years of programming against REST(ish) APIs backed by statically typed languages, I'm now fighting one built by a team that loves ruby/rails.
It's a terrible experience. No auto-generated specs. Can't even look at the code to know what some request parameters are supposed to be (had to go digging through pagy docs for that one). One day, a value in a response that is normally a string was suddenly an array on certain queries.
The whole approach is so haphazard move-fast-nobody-cares that it grinds my gears and I'm not even contributing to their code, just consuming it.
My kingdom for a better experience.
- herbst 2y agoSounds like a bad API and not specifically Ruby issues.
- zdragnar 2y agoThe lack of openapi anything is a weakness of the ecosystem, as there's a ton of tooling that's left on the table. Even Python has a bit of a leg up here. On top of that, the number of bugs that could have been avoided with static types is a bit depressing- the only true way to avoid them entirely is duplicating what you get from a static language, but manually with extra unit tests. There's plenty of really nice things about Ruby and rails, but you don't actually get features faster without sacrificing something. The team puts out code at more or less the same pace as I would have expected from teams working with other languages, though I haven't seen so many nil errors since working with a bad Java code base.
- nasmorn 2y agoJust added open api to a rails API with rswag. It works by making the definition and then running your request specs against it. That certainly can make a lot of sense for your consumers