0

Suppose we have a site on Google Firebase Hosting that routes some requests to a Google Cloud Run service. The service is considered entirely an implementation detail and its only client is the single website. The only reason for using a Cloud Run service is that it is the only suitable technical option within the Firebase platform.

Now, suppose that the API of the service may have a breaking change with every update, so the Firebase Hosting content must change too. How do you update or roll back both parts together so as to avoid incompatibilities?

Straightforwardly, we can update the service and the site content in separate steps, but that means some requests from the old revision of the site may reach the new revision of the service or the other way around, causing errors due to API mismatch. The same issues are present when rolling back the site content and the service at the same time.

One theoretical solution would be to deterministically route requests to different service revisions based on revision labels, but that is not supported on Cloud Run.

One realistic solution would be to create a new service for every update of the site content. However, that would result in unbounded accumulation of services which are not automatically deleted like service revisions are.

Another solution (proposed below) would be to maintain backwards compatibility in the service - it would support both the latest and the previous API version. However, this can be considered an unnecessary overhead. Since the two parts (static content and the service) have no real need to ever be updated independently, it would be very convenient to avoid the overhead of maintaining backwards compatibility in the service.

Jakob Leben
  • 305
  • 2
  • 5

1 Answers1

0

For what I know there is no way to make this update in a single transaction to avoid this behavior you mentioned as Firebase and Cloud Run are different products.

Also a good Practice in API design is to allow Service Evolution this means that updating the API shall not break the apps consuming it and new versions of the app shall be able to evolve in a way that they can consume the current API.

Something that is done when a new API will not allow retrocompatibility is to have different endpoints this is why some APIs are apiName/V1/method and apiName/v2/method but in this case both versions of the API are deployed.

Soni Sol
  • 2,367
  • 3
  • 12
  • 23
  • I wholeheartedly support the ideal of smooth service evolution when an API is public. In the proposed case though, the Cloud Run service is considered entirely an implementation detail and its only client is the single website. Since the two parts (static content and the service) have no real need to ever be updated independently (beyond technical limitations of the platform), it would be very convenient to avoid the overhead of maintaining backwards compatibility in the service. I will clarify that in the original question. – Jakob Leben May 22 '20 at 01:04
  • As this are two different products even though both are running in Google infrastructure there is no way to update them in a single transaction, the closest you can achieve is by using a deployment tool is to update them together but there will be a short time with one thing in v1 and the other in v2. To allow the compatibility for this what you can do is the approach of two API versions differentiated on the URL, and update the cloud RUN first to avoid breaking the app. – Soni Sol May 22 '20 at 19:39