5 ms·

> That means that when one side of the API changes, the other side won't even compile until it's updated to match. Coupling your front end and back end in this

> That means that when one side of the API changes, the other side won't even compile until it's updated to match. Coupling your front end and back end in this way can give you false confidence in making API changes. If you control both sides of the API on a web app that doesn't have too many users yet, then this can be very productive, but consider this situation: You've made a breaking API change on the back end, and thanks to your type system, you make the corresponding front end changes as well, which is great. You deploy your code, and the back end changes take effect immediately. Visitors who were in the middle of a session are still running the old front end code, and their requests start failing. Cached copies of the front end start failing too. You can engineer around this but it's better to have a system that doesn't make introducing breaking API changes too easy. It should be painful.

jkaptur 7y ago
And if you do a gradual rollout, newer clients can connect to older backends! And if clients can talk to each other, there can be THREE versions involved. Also: rollbacks. I’m curious if anyone has a system for managing this that they love. I’ve pretty much only seen painful ways.
- n0w 7y ago
  I think in an ideal world you would do API changes to a live system in much the same way as you do with a live Database Schema: Carefully, and in a backward compatible manner.
- hamandcheese 7y ago
  At <dayjob> we use flow types and graphql, so like OP our frontend will fail to compile if we make a breaking change. To assist with the backward-compatible-during-deploy issue, we additionally have a teensy bit of tooling that comments on our PRs to indicate dangerous API changes. It's not perfect (I've ignored the comments before, thinking I knew better... I didn't), but it seems to help. It wouldn't be difficult to make it more sophisticated, and then completely block PRs it knew weren't backward compatible, but we haven't seen a strong need to do that yet.
joshAg 7y ago
When you control both front-end and back-end, you don't have to make a breaking change that will affect anyone at all, if you're willing to do a multiple deploys and maybe wait a little bit. If your want to change from A to B, your first deploy is deploying B without stopping A from working. It could be a totally new endpoint, or you could just throw a version field into the request body or querystring. Once everyone has switched off of A, you can remove it from your codebase so only B remains without actually affecting anyone's session. If you don't want to pollute all your querystrings or request bodies with version fields, you could have an optional newVersion boolean field that only needs to appear during a switchover or make a temporary endpoint for updated clients to hit instead of the old endpoint: # state at start /foo <- uses API A # deploy new endpoint /foo <- uses API A /foo/new <- uses API B # wait for everyone to swtich to /foo/new, then deploy API to /foo, removing support for API A (this could be split into two deploys if you wanted) /foo <- uses API B /foo/new <- uses API B # wait for everyone to switch over to /foo, then remove /foo/new /foo <- uses API B
BiteCode_dev 7y ago
If you don't have typing, you'll have this problem too.
MaxBarraclough 7y ago
> You can engineer around this Right, just version the API, or have the app refresh itself when appropriate. Isn't this a fairly straightforward issue to address? Also, as BiteCode_dev points out, this issue has nothing to do with whether you use a static type system.
flohofwoe 7y ago
MMO games like Guild Wars handle this problem by deploying a new server version in parallel to the running old servers and keep sessions in progress connected to the old servers. New sessions will connect to the newly deployed servers, while old sessions eventually "dry out". Old server processes with no active connections shut themselves down. IMHO that's an easier solution than having to implement a backward compatible API or other API versioning solutions.
ttty 7y ago
In https://game.bitplanets.com https://game.bitplanets.com I have `gameVersion` that will change when I make breaking changes. Then the client kind of understands that the client version doesn't match the server version and it will refresh.

jkaptur 7y ago

And if you do a gradual rollout, newer clients can connect to older backends! And if clients can talk to each other, there can be THREE versions involved. Also: rollbacks. I’m curious if anyone has a system for managing this that they love. I’ve pretty much only seen painful ways.

n0w 7y ago
I think in an ideal world you would do API changes to a live system in much the same way as you do with a live Database Schema: Carefully, and in a backward compatible manner.
hamandcheese 7y ago
At <dayjob> we use flow types and graphql, so like OP our frontend will fail to compile if we make a breaking change. To assist with the backward-compatible-during-deploy issue, we additionally have a teensy bit of tooling that comments on our PRs to indicate dangerous API changes. It's not perfect (I've ignored the comments before, thinking I knew better... I didn't), but it seems to help. It wouldn't be difficult to make it more sophisticated, and then completely block PRs it knew weren't backward compatible, but we haven't seen a strong need to do that yet.

joshAg 7y ago

When you control both front-end and back-end, you don't have to make a breaking change that will affect anyone at all, if you're willing to do a multiple deploys and maybe wait a little bit. If your want to change from A to B, your first deploy is deploying B without stopping A from working. It could be a totally new endpoint, or you could just throw a version field into the request body or querystring. Once everyone has switched off of A, you can remove it from your codebase so only B remains without actually affecting anyone's session. If you don't want to pollute all your querystrings or request bodies with version fields, you could have an optional newVersion boolean field that only needs to appear during a switchover or make a temporary endpoint for updated clients to hit instead of the old endpoint: # state at start /foo <- uses API A # deploy new endpoint /foo <- uses API A /foo/new <- uses API B # wait for everyone to swtich to /foo/new, then deploy API to /foo, removing support for API A (this could be split into two deploys if you wanted) /foo <- uses API B /foo/new <- uses API B # wait for everyone to switch over to /foo, then remove /foo/new /foo <- uses API B

BiteCode_dev 7y ago

If you don't have typing, you'll have this problem too.

MaxBarraclough 7y ago

> You can engineer around this Right, just version the API, or have the app refresh itself when appropriate. Isn't this a fairly straightforward issue to address? Also, as BiteCode_dev points out, this issue has nothing to do with whether you use a static type system.

flohofwoe 7y ago

MMO games like Guild Wars handle this problem by deploying a new server version in parallel to the running old servers and keep sessions in progress connected to the old servers. New sessions will connect to the newly deployed servers, while old sessions eventually "dry out". Old server processes with no active connections shut themselves down. IMHO that's an easier solution than having to implement a backward compatible API or other API versioning solutions.

ttty 7y ago

In https://game.bitplanets.com https://game.bitplanets.com I have `gameVersion` that will change when I make breaking changes. Then the client kind of understands that the client version doesn't match the server version and it will refresh.