HTTPRoute - routing to a large number of urls?

[meastp]

Hi,

I want to use the Gateway API for routing (north-south) with HTTPRoute. The service consists of hundreds of datasets (=postgres database for each dataset), and the url to each dataset use an uuid to identify the dataset, like this:

• /app/uuid1/data
• /app/uuid2/data
  ...
• /app/uuidN/data

During normal operation, I just route /app/* to my service, of course.

I'm wondering how this will work during an upgrade, because I would like to be able to use a canary-style upgrade where I change the routing to individual datasets to point to the new version for tesing. In case of database schema upgrades, I also want to migrate the datasets one-by-one to avoid downtime on multiple datasets at once.

I guess all the urls need to be typed out individually then, and which service they point to?
How efficient will this be if there are 100 or 1000 urls?

Is there a way to point to no service and get 503 Service Unavailable[1] instead? That would be perfect when migrating the service if database schema migrations that require no user traffic are needed.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503

[robscott]

In case of database schema upgrades, I also want to migrate the datasets one-by-one to avoid downtime on multiple datasets at once.

One possible solution would be to rely on the fact that exact matches have precedence over prefix matches:

gateway-api/apis/v1/httproute_types.go

Lines 164 to 173 in 28880c1

	// Proxy or Load Balancer routing configuration generated from HTTPRoutes
	// MUST prioritize matches based on the following criteria, continuing on
	// ties. Across all rules specified on applicable Routes, precedence must be
	// given to the match having:
	//
	// * "Exact" path match.
	// * "Prefix" path match with largest number of characters.
	// * Method match.
	// * Largest number of header matches.
	// * Largest number of query param matches.

In practice that means you could have an exact match for the instance you're migrating (/app/uuid1/data) for example, and fall back to a prefix match for everything else. Of course I may be missing some nuance of your use case here.

How efficient will this be if there are 100 or 1000 urls?

That will depend on your underlying implementation.

[meastp]

Thank you - I will re-ask the question directly to the implementations :)

Also, the prefix-match-fallback will save quite a few paths/matches/urls :)

[meastp]

At least, no worries from nginx nginx/nginx-gateway-fabric#1292

[meastp]

Would this be a valuable (simple?) extension to the Gateway API, since the alternative is to create a Pod/deployment with an image that just responds with 503?

Is there a way to point to no service and get 503 Service Unavailable[1] instead? That would be perfect when migrating the service if database schema migrations that require no user traffic are needed.