Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement data portal router #972
Versioning of client apps and servers in sync can be problematic. This is particularly true for smart client scenarios, especially mobile clients (where deployment may occur over time due to Apple/Google/Microsoft stores).
This means the simple n-tier model for CSLA apps
may not be adequate. Versioning in this case means standing up versioned endpoints. For example:
And that's fine - that's what I've been recommending people do for years. And that's OK in some cases.
But in other cases it would be far better to have a single public endpoint for all client devices to invoke, and then that endpoint could route calls to non-public versioned endpoints.
In this case the public endpoint would be consistent:
And the "behind the scenes" endpoints would be versioned:
This is particularly beneficial in a Docker/Kubernetes scenario, where the public endpoint is defined as a K8s service and has public security and configuration, while the K8s cluster runs n appserver-v1 and appserver-v2 instances based on load - but without the public security/configuration concerns.
Also, in a K8s scenario it is possible (if desired) to run all three containers in a single pod, allowing the public endpoint to route to "localhost" endpoints for each version of the actual appserver, differentiated by port number:
Either way, what's needed is a data portal router component that exposes the public endpoint and routes each call to an appropriate private server endpoint.
My plan is to implement this only for the HttpProxy/Host channel, because I can do that without deserializing/reserializing the message payload on the router (I don't see how to avoid that with WCF...).
It should be possible to add a version element to the payload sent from the client-side dataportal to the server, right alongside the serialized object graph. That version element can be used to route the call, with minimal overhead, to the version-specific private server endpoint.
This is now implemented for
The scope of the change has changed somewhat. As per the original request it does handle routing based on app version. However, it now also allows per-type routing so data portal operations for specific root domain types can be routed to specific servers in a cluster.
There is now an
There is now a
The client-side data portal passes a routing tag to the server with the following format:
If you haven't specified either value no tag is passed. If you specify only a per-type routing tag the format is:
If you specify only a version tag the format is:
In the server-side