Question:

in teams with backenders and frontenders, how do you guys coordinate introducing breaking changes to the API while the system is live ?

we change bkend and then blame frontenders when things stop working :)

/jk

create a feature branch, do what needs to be done, await front-enders to do their part, and merge

@C0D4 that sounds good, thank you

@C0D4 but now that I think about it, when merging and deploying, the system wouldn't be available for couple of seconds/minutes, isn't that bad?

@uuid depends how you're deploying and how time sensitive the system is, does it need to run 24/7?

usually you'll schedule an hour to two at a very low usage period to deploy the changes so the affected users / dependent systems are kept to a mininum.

what kind of system are we talking about here?

im assuming a website but you haven't given much detail there.

@C0D4 it's not a website, more like a web app which should be available at all time and we can't afford for it to be down nor users experiencing issues due to the breaking changes.

@uuid in that case I would still find a low user period to deploy the changes (I hope you have analytics of some type) or setup rolling deployments (if the webapps servers are scaled) so that you won’t be affecting many, or if any users as they will be pushed over to a new instance of the web app as it becomes available to them, and the current instance is taken down.

Worst case go old fashioned and show a “we will be down between x and y” for a few days so the downtime is atleast planned for by both your team and the users.

Some info on blue/green or rolling deployments.

https://medium.com/@mateusfreira/...

@uuid go for something like Jenkins. Build it on the server and replace and back it up. If you have 5 seconds of downtime it's long.

@BrianK we have jenkins and CD workflow.

@C0D4 blue/green sounds interesting, I'll checking it out, thanks

API versioning. All endpoints start with /vx/... breaking changes = new version. Deprecated API versions are left running for a few months unless they have serious issues.

@ItsNotMyFault API versioning is indeed a better solution, but unfortunately, my team is not ready for it yet.

I don't understand.

Do you have a dev shared environment of your application?

Is this supposed to stay live? I don't think so

Versioning of your api is always nice, especially when the backend API is public to multiple applications.

Other way of doing it is to initially add stuff and only remove when the frontend changed their code to only use the new stuff. This way you’re always backwards compatible. Things could get ugly tho if you add too much.

Original api endpoint: /v1/endpoint
New api endpoint: /v2/endpoint