This stuff was foundational to the modern web and it's clear the maintainers, who probably are not Steve Jobs, have no idea what will break as a result. If it's removed, it will just get added back in after the outrage

500 people out of work. Tell me again how simple everything is to fix.

eg Tap on a bus, tram and train in Melbourne, get off in Wangaratta and tap on to a bus there.

There was going to be something like 29 zones, and all the requirements / edge cases / mucking around sent the cost through the roof.

Comments URL: https://news.ycombinator.com/item?id=36476050

Points: 2

# Comments: 1

I get the problem though, many of the libraries are not great or simply difficult to use

I certainly don't want people building security sensitive parts of an app to be slinging the features out.

Refresh tokens are your chance to do all the expensive checks - maybe you are IP restricted or want to step up with MFA etc etc. Check revocation etc

Still, people buy Dell Boomi and Mulesoft, so it's not like there's no market for this rubbish

Comments URL: https://news.ycombinator.com/item?id=35054278

Points: 11

# Comments: 1

This diagram, which was intended to be a rough snapshot of how the systems interacted, instead became the single point of reference for how everything in the company worked. It was used to justify investment, knock back projects, one PM even tried to use it to dragoon AD into a PCI Compliance project due to a couple of lines on the aforementioned diagram (like this system has cards, line goes to Exchange as it alerts via email and AD is connected to Exchange. AD is now on the PCI hook).

It was the first thing I did there, leaving 4 years later. They were still in wide use 3 years after I left and hadn't being updated since they were drawn, not to mention they were flat out wrong in a number of significant ways to start with (either simplified for $REASONS or just didn't find out the real story until a year or 2 later).

These diagrams are probably the most impactful thing I've ever done in my career given how long they remained in daily use and the effort to draw them (which was probably a week or two? Took a long time to get the data but the drawing bit was pretty quick).

Would code have made them more accurate or likely to be updated? I doubt it. Would it have made them more useful? I don't think so, the key to them being well understood and useful was mostly in the layout, something that is difficult to control in any generated diagram.

I did actually have a go at using structurizr when I was there but it was too much work when compared to knocking out a quick draw.io.

Personally these days I make great use of PlantUML / WebSequence diagrams and am very interested in the C4 / mermaid stuff, but I would likely take the approach of the Engineering Manager - please produce diagrams and make them: 1 - accurate and 2 - useful for whatever story you are trying to tell.

Do it in code if you can make it work, but as someone in the thread said - this is an old problem and if it was easy it would have being solved in the 90s.

That said I've always thought a dependency system would be a good way to express the relationships between systems - you could almost model systems using something like maven poms - but again, it's always too hard to get the scope and resulting view right.

If you: - have more than 1 upstream service to hide behind your api.bigcorp.com name? - want to enforce standard authn/authz patterns across lots of teams/backend services? - want a standard approach to all the Quality of Service management? - want to have a well defined lifecycle for your APIs? - want to have a portal that describes the APIs, how they work and facilitate users getting access to them?

API Gateways are a thing because web servers that started out being used as reverse proxies were not that easy to configure and just did way too much web server stuff. API gateways made this easier, and added a host of security measures to make it somewhat safer when presenting APIs to the internet.

Then API management came along as a first class concern for orgs who want others to use their APIs.

It's good to see some FOSS innovation in this domain, most of the real open source API gateways are a huge mess. Kong is great, but the really useful stuff is part of the paid enterprise platform.