Why you should version your api endpoints 

I think api versioning is particularly most useful when the api is used by mobile applications because as we know updating mobile applications is way more complicated than the click of a refresh button like in webapps, although for webapps there may be caching issues but still they should be easier( I expect) to deal with.

Great video. Definitely is something you need to think about. If your app lives behind a login, a technique I've used before is a /revalidate endpoint that checks if a user needs to re-login. When combined with react-query (refetch queries on window focus), you get lots of control.

Nice explanation, and drawing the diagram made it easier to understand. Thanks so much!!

These videos are so invaluable. Especially when I cant understand some of these articles or concepts myself.

Love these kinds of videos. I can watch them even when I am burned out

Your diagrams are so useful for a visual learner like myself. Thanks Cody!

Love the content Cody, thanks for posting :)

The expand then contract strategy works well for breaking DB schema changes, and a similar concept can be used for these breaking API changes as well. You basically add whatever you need to your API to satisfy the new requirements, then optionally test it first, then you deploy the changes on the user/frontend side that consumes the updated API, then you wait X amount of time (usually depending on caching strategies and time until you're confident 99% of users are on new version. can optionally roll-back easily now as well, if errors spike with users on the new version), then you deploy the breaking change, which "contracts" the API schema to the final state. The multi-deployment strategy you explained & vercel seems to use is ofc easier to use and probably preferred for most web apps. Just wanted to mention an alternative approach :)

Love it! And love you!

Great video! good to know this

Hey Cody, could you do a video explaining Ci/Cd and maybe building one with something like github actions

I think we can provide something like a UI version request header and then API will check if this UI version is compatible with this API version and if not response with some header or error code which UI will know that it's now incompatible with API and just refreshes itself automatically. What do you think about this approach?

Sometimes I feel like web is doing too much backward compatibility works unlike native client that just ask user to hard update the native client otherwise they cannot use it. We are being too nice for breaking changes and at the same time we got more complaint from users. The whole backward compatibility thing is what makes web amazing and long live but it also holds the entire web development back.

I feel like simply "returning to monkey" and having some automated way to just attach a build ID to all the requests is better. If the backend receives a request that is outdated, force a refresh.

What are you studying for know all this things?

Why couldn’t the UI just simply watch for a flag that tells the UI it’s on an old version and if it is go ahead and refresh the page? That seems to be a very simple solution to me. Let’s say UI makes request to old API, and the old API would need to have some sort of way of knowing it’s old, and in the response of the old API back to the user, we send a flag back to the UI that says something like “uiVersion: version_number” and if it doesn’t match the UI version then the UI will automatically refresh and retrieve the new assets. Every API could make a chron job every so often that checks for an update in the UI, or you could broadcast it over a simple websocket that connects the API versions together, perhaps an internal router can be checked before the API code and the check can be done there instead of the API. That’s seems easier than immutable deployments, at least it does in my head. IDK, it doesn’t seem that much easier though, I do think Vercels solution is very nice too.

graphQl is the easiest way to manage this problem