I would like to add a feature in "pub serve" that provides proxying functionality to connect to a different back-end. Thus the intended high-level flow of a request from Dartium would look similar to:
User request from Dartium goes to BarbackServer
BarbackServer searches for an appropriate local asset
If one is not found, and the 'pub serve' argument '--proxy' is set then forward the request to the server pointed to by --proxy
If the response is a 404, then continue with the usual BarbackServer 404 handling
If there is a response, pick it up, then write it back to the response
I believe this would help folks who would like to use the DartEditor to build and test their code, but would like to use a different back-end server. By having their requests fall back to a proxied back-end server, they will not have to leave the Dart Editor or Dartium. Also, during production deployments, there would not be a need to change any code. This would only be useful when front and back end are on the same server.
Please let me know if this is sound and useful or if I am looking at the whole dev cycle incorrectly.
The text was updated successfully, but these errors were encountered:
I believe this would help folks who would like to use the DartEditor to build and test their code, but would like to use a different back-end server.
This is a use-case we care about, but I don't think this is likely to be how we address it. When integrating with an external server, it's important that we give that server a lot of control over where and how the Dart assets are presented, since integration requirements vary wildly from person to person. That suggests that doing this in reverse -- having the application server proxy to the barback server -- is a better strategy than having "pub serve" itself do the proxying, which requires that the Dart assets be served from the root of the directory.