I remember my engineer being such a hardass on using v2 of our API and when I went to implement a feature, v2 didn't even have ANY of the endpoints I needed

[–] db0@lemmy.dbzer0.com 35 points 2 days ago (4 children)

I don't get why anyone would publish v2 when it not really on feature-parity. Do companies really start releasing v2 endpoints slowly?

[–] GTG3000@programming.dev 5 points 18 hours ago

In my experience, it was an attempt to prune the stuff in old API that wasn't useful. A successful attempt, since the backend working on it was in the same room as me and I could yell at him.

[–] lime@feddit.nu 40 points 2 days ago (1 children)

it's called the strangler pattern, where the new version is layered on top of the old and gradually replaces it.

it usually doesn't work.

[–] tyler@programming.dev 3 points 18 hours ago (1 children)

Man I’ve never seen it not work. It’s pretty much the only pattern I use because it’s so successful. Meanwhile the other teams in my company have numerous failed migrations because they try to rewrite the entire thing at once instead of using the strangler fig pattern.

[–] lime@feddit.nu 1 points 16 hours ago

only time i've ever tried it was in a duolith consisting of over half a million lines of python, all of them critical.

[–] Aceticon@lemmy.dbzer0.com 6 points 2 days ago

I suspect that starting your own version of the API is the Software Designer / Software Architect version of Programmers' "I know best so I'm going to do my part of the code my way which is different from everybody else's".

Mind you, at the very least good Software Architects should know best, but sometimes people get the title without having the chops for it.

[–] stankmut@lemmy.world 4 points 1 day ago (1 children)

If the APIs are meant for public consumption, requiring feature parity makes a lot of sense. But when it's for internal use by your own developers, waiting means you are making a bunch of new API endpoints no one will ever use. People will write more and more code using the older endpoints and those endpoints will start getting changes that your new ones will need ported over.

I think if you are going to force people to use new endpoints, you'll need them to either write the endpoints themselves or have a team member who can write it for them and account for this while planning. If getting a new endpoint requires putting in a JIRA ticket with a separate backend team, 4 planning meetings, and a month wait, people are just going to stick with what currently exists.

[–] ByteJunk@lemmy.world 4 points 1 day ago* (last edited 1 day ago)

This is how we have 3 different APIs that sometimes do the same thing, but most times are incomplete when compared to the original v1, who in the meantime wasn't properly maintained because we were "migrating" and now you have to use bits and pieces of the 3 of them to do anything.

It's a nightmare. Can't wait for the next genius to come along and start a v4, that will never be completed and will only re-implement parts of the old APIs while implementing all the new features

[–] stankmut@lemmy.world 3 points 2 days ago (1 children)

In my experience, having to write new v2 (or in my case v4) endpoints for most new features was expected.

[–] bijectivehomomorphism@programming.dev -1 points 1 day ago (1 children)

v4???? At that point I'm just gonna guess the data

[–] stankmut@lemmy.world 3 points 1 day ago

It was basically the same thing. In the code base, there was only v3 and v4. I never bothered to check what happened to v1 and v2, but I suspect they were used in an older, archived code base.