[connor4312]

> the simple internal data model was replaced by a dense and non-orthogonal data model with different types for leases, locks, transactions, and plain-old-keys

I maintain a (/the only?) etcd3 library for Node.js[0], and used etcd extensively on my former team.

None of these things are new to etcd3 API. All of these are present on v2 as well[1], whose API the author extolls, or are built within clients on etcd's base APIs (e.g. there's no 'lock' API, only leases). However, with etcd3 we get stricter typing, better performance, and better semantics (e.g. watch streams and lease streams over polling) thanks to GRPC.

In general these rich APIs allow 'average' engineers to build complex distributed apps more correctly. I've built reliable sharding, hash rings, elections, and so on based on etcd's API--none in more than a hundred or two lines of code (more in Go, less in Node.js). All of these are classic hard problems that etcd makes easy. Sure, there's innumerable standalone services for each of these things, but often there's no need to take the cost of many tools when one would work.

0. https://github.com/microsoft/etcd3

1. https://etcd.io/docs/v2/api/

[mst]

I feel like the blog post could largely be summed up as "stop threatening to remove the normal HTTP API, some of us find that a lot easier to debug and ease of debugging is essential for a core operational component of a distributed system" - which is, I would argue, an entirely reasonable thing to want.

I quite enjoyed the rantiness on a "being entertained" basis but it did rather work against effectively making the core point.

[umvi]

> stop threatening to remove the normal HTTP API, some of us find that a lot easier to debug

I've seen the trend toward complexity in other projects too, and it harms not just ease of debugging, but ease of hacking.

Take, for example, Swagger UI[0]

v2 was so simple. It was vanilla JS using jQuery. I, as an embedded systems developer, was able to easily hack it so it could read in the OpenAPI JSON from a database and I even added a little search box so you could filter down the APIs you wanted to see. Super fast and easy and worked just the way I wanted it to!

Starting with Swagger UI v3, it became... extremely labyrinthine by comparison. It was completely re-written in React JS and now I need a bunch of new tooling to make changes and everything was broken out into dozens of different modular files so I couldn't find where I needed to make a given change, also not to mention I've never used React so it felt like the barrier to hackability was dramatically increased.

I'm sure full time React folks love the new architecture because it's so much <cleaner/safer/scalable/etc>, but for me the change was extremely confusing and made the tool unhackable (I tried for a few hours to get it to do what I wanted, but it started looking like I was just going to have to learn all of React and I threw in the towel), and so I'm permanently stuck on v2 for now.

[0] https://github.com/swagger-api/swagger-ui

[cartman82]

I am a full time react folk, and I hate it.

[threeseed]

Complaining about an open source project changing technologies because you can't be bothered to learn them is a bit rich.

Fork Swagger v2 and make your own improvements. No one is stopping you and it's what open source is all about after all.

[umvi]

> Complaining about an open source project changing technologies because you can't be bothered to learn them is a bit rich

Web technology is its own beast. I invested a long time learning and mastering AngularJS only for all that work and knowledge to be flushed down the toilet over the next few years. Web tech has terrible ROI so that's why I "can't be bothered" to learn the latest one. I'm salty specifically about Swagger jumping on <insert latest framework> instead of sticking with simple vanilla JS that everyone understands.

> Fork Swagger v2 and make your own improvements

Yeah, that's exactly what I did...