In a normal application with front and back separated, how do you guarantee consistency between models? Do people normally do PRs to change them on both sides and hope none screws up or is there a better way?

Some time ago I was looking into generating stuff from the OpenAPI spec. Is this a good idea? Also, can graphql help with this? I'm soooo confused by this, it's like a problem I never managed to solve in my head...

I’ve used OpenAPI to sync interfaces, it’s quite nice! Single source of truth for network models, and then you can map/transform that as you want to make it nicer for either front/backend usage

Usually that is one reason why there is so much infighting among devs - front-end devs are horrible at explaining how they need their data objects to be structured, and back-end devs are slow to implement what at first seem to be small changes.
I have never found a one-size-fits-all solution for this.
Those GraphQL or mandated canonical models for standardized APIs or whatnot come in handy when you are selling API access, so the frontend is in another company anyway and there might be many client applications for the same API.
But when you are messing with a full-stack application, management will see those middleware conventions as a source of delay, and will push for "small adjustments" so often that the entire idea of standardization gets the muck.
I'm afraid that this problem is an honorary member of the NP-Hard class.

@TheCommoner282 you can reduce the Front-end/Back-end data model compatibility problem as a special case of the system-system data model compatibility problem.
Solve the system-system compatibility probem efficiently, optimally and completely, and you might have solved every cultural conflict ever.
And if that does not make it an honorary member of the NP-Complete class, I don't know what would.

If you're in control of front- and backend, a monorepo is the key. All changes can be tested as an "atomic unit". All developers have to commit into the same repo and you can make sure a feature-branch is stable before merging and deploying.

If that is not possible, you basically have the same problem as public API providers: You have to support old API / models until you are sure they are not used anymore.

We have that too and we either add backward compatible changes to the models (optional properties) or create new versions of it that are available through new (versioned) service APIs. Hard work that will teach you to take time for API design. :)

I got too tired of making things consistent at one point since we have a middle service that relays calls to an internal service. So I ended up returning json strings all the time lol.

The only thing it missed was the examples on swagger ui.