This is the way.

> Companies genuinely don't want good code.

I might be more charitable. I'd say something like "Companies genuinely want good code but weigh the benefits of good code (future flexibility, lower maintenance costs) against the costs (delayed deployment, fewer features)."

Each company gets to make the tradeoffs they feel are appropriate. It's on technical people to explain why and risks, just like lawyers do for their area of expertise.

Ding ding ding!

The article talks about process flows and finding the bottleneck. That might be coding, but probably is not.

> Why not? Why can't faster typing help us understand the problem faster?

I think we can, in some cases.

For instance, I prototyped a feature recently and tested an integration it enabled. It took me a few hours. There's no way I would have tried this, let alone succeeded, without opencode. Because I was testing functionality, I didn't care about other aspects: performance, maintainability, simplicity.

I was able to write a better description of the problem and assure the person working on it that the integration would work. This was valuable.

I immediately threw away that prototype code, though. See above aspects I just didn't need to think about.

>There's no way I would have tried this, let alone succeeded, without opencode

Sure there is.

You could have used Claude or Codex directly :)

Oh man, that makes me sad. Because when you publish on the public web, you never know who you are helping.

Private groups or in-person meetings are great too, but foster way less learning.

But I get your reasoning, for sure.

I posted this because using an authorization server like OpenFGA creates a real issue: syncing authorization related data.

There's identity data that needs to be synced (from an identity provider). This seemed like a cool open source solution for that. It's not enough, of course.

You also need to sync data between your application/domain and the authorization server to have accurate authorization decisions. But other than using the authorization server's SDK, I don't think there's a general solution to that problem.

Disclaimers: I have not used this software. I don't know if it is maintained. I also work for a company that has competitive offerings for both Keycloak and OpenFGA.

Actually, you don't _need_ to sync data, you can send it contextually too https://openfga.dev/docs/interacting/contextual-tuples.

Of course, if you end up sending all data contextually, you are better suited with a different solution that does not require a server roundtrip like Cedar.

This repo compares differences between the OpenFGA approach and the Cedar approach https://github.com/openfga/openfga-cedar-comparison

In your view why is using the AuthZ server SDK not a good solution - or maybe other way around, what would be a more general solution?

I was more musing than anything else. I don't think application data is standardized enough to use a more general solution. This is true across all AuthZ servers; it's not an OpenFGA problem.

Maybe there's a mapping layer that is possible (similar to ETL) that moves it out of code into configuration? But I'm not sure.

I agree that I don't want my vacuum cleaner to have my government id :) .

But there's a spectrum. I think expecting my vacuum cleaner to limit my access via any API (documented or not) to my own devices. Seems like a small ask.