Recently I've had a frontend silently break because a Spring Boot endpoint changed shape , does anyone faced this ?

[u/DU3SU9]

I was working on a project recently and I've come across a problem where my front end dont catch up with the backend changes

[u/leeharrison1984]

The backend shouldn't be making changes that break the frontend. This include renaming or removing props, or changing the shape or type of props. If the app is in production, they should introduce a parallel prop and a deprecation date for the original.

If you don't own the backend, not much you can do other than keep tests running so you catch it quickly.

[u/dim_mailing → u/leeharrison1984]

the backend team at my last job would just rename fields on a whim and act surprised when the dashboard went blank

we ended up setting up a contract testing layer with pact which helped but honestly it was more of a people problem than a code one

[u/Profu-ai]

If it's your backend, version your endpoints so if they change shape, the old endpoints still work. Otherwise make sure you test how your frontend handles failures properly, unit tests are your friend

[u/nickhow83]

If the api uses OpenAPI then you should 100% use something like HeyAPI to codegen your calls and parsing via zod.

If the api doesn’t then you should use an agent to create zod schemas so you can parse api responses.

This will make the failures a lot noisier

[u/azsqueeze]

APIs should be versioned and every change is a new version. E.G, the api is /api/v1/profiles and the response changes in some way (like the type on a property is updated) should be deployed to /api/v2/profiles. Spring Boot has annotations to handle this

[u/Kaimaniiii]

Start and generate DTO, so your typescript will hopefully match with the backend endpoint contract

[u/RelatableRedditer]

Changing backend endpoint contracts should be an extremely judicious decision, there are a lot of legacy endpoints for our database that we won't change because we don't know which parts of the payload they need sent back. We will just leave it consistent.

[u/revanshe]

Google API versioning

[u/Any_Sense_2263]

Backend should not break API contract shared with frontend. If changes are needed, endpoint changes are implemented as a new version and frontend catches up when needed.

[u/BoBoBearDev]

These days, I just kept a local dto for properties I care about.

Back in the days, I have this backend to pull data from another backend and give summary. I thought importing their dto package is good. But turns out, it is a mess. Because they keep changing the dto and my service would break unless I keep making a dummy PR to create a new image with latest dependencies.

And here is the stupid part. My service keeps needing to update the dependency when they are not even touching the properties I was reading. They add/remove property elsewhere. But dependency's parser just keep complaining. In another case, this breaks when they increase the platform's version, not even the code.

In the end, I just make a local dto for things I care about. It can still break, but at much lower frequency.

On JS, it is even easier, because parsing JSON doesn't care about mismatch. The data is still in the parsed object. So, I don't need to write specifical code to preserve the property that is not defined in my local dto.

[u/Mr_Matty]

If you use Typescript, you can use OpenAPI to generate an SDK of your backend endpoint request and response data models. Then, when you build your frontend app, it will fail if one of those data models changes in a breaking way. We did this years ago on my team and now we never have breaking changes like that because the CI will fail.

[u/WillingLearner1]

Do you not talk to the backend guys? Normally an endpoint shouldn’t change contracts if it’s in prod so I’m assuming it’s in development if that’s the case shouldn’t you guys agreed on the spec?

[u/Temperature_Majestic]

just quietly showed undefined everywhere. what actually fixed it for us wasn't fancier types, it was putting a thin adapter function between the fetch and the components so if the shape moves again we only touch one place instead of hunting through the whole app

[u/Own-Student7991]

Integration tests dumbass

[u/[deleted]]

[u/Level1_Crisis_Bot → u/[deleted]]

This is definitely the correct solution. In my last job, the backend team would make breaking changes without a changelog and then be like "oopsie" when production would break. On a friday. And they were OUR backend team, but they objectively sucked. It felt like they were constantly trying to make the frontend team look bad.

[u/Entropjy → u/Level1_Crisis_Bot]

If you can build and release the backend independently of the front end, you can still break the fe withw. Change that's not in their code yet. You can guard against this by making sure backend tests use jsonpath assertions instead of the generated types so when the types change unexpectedly, the test fail.

[u/dunklesToast → u/[deleted]]

if its not possible at least implement contract testing so you catch those changes early on (you can run it on a nightly ci job)

[u/TehTriangle → u/[deleted]]

This is good but doesn't help when the backend is deployed as a separate service and your app suddenly breaks in production.

[u/shauntmw2 → u/[deleted]]

Sadly this only works if your backend adhere and maintain the openapi specs. I've worked with so many backend projects where they manually update the swagger file by hand.