Introducing Project Proxies
For our third new feature highlight of Maque 1.1 we will be taking a peek at the new Project Proxy passthrough settings and how they can help improve your development workflow. It is especially helpful with the new Proxy Rules and session based authenticated projects.
Take form of Proxy!
When you create a new project, you now have the option to Enable Proxy and provide a Proxy URL. You can also enable/disable this feature for any project using the File > Update Project Configuration... menu. Enabling this feature changes how Maque handles incoming requests to the Maque server. The default behavior is for Maque to compare the request to the project's existing Services & Rules. If the request does not match any of the Services & Rules, then the server checks the htdocs folder to see if any files match this request. If no files are found, then Maque returns a 404 Not Found back to the requester.
When you turn on the Project Proxy you are telling the Maque server that any incoming request for this project, which cannot be matched, should be forwarded to the URL. Maque will then return any response back to the requester. In essence, Maque becomes a proxy server that forwards and returns any response to the URL provided.
You want to go where?
In previous versions of Maque, the preferred way to configure an application was to change the service URL in the code and point all outbound requests that you want to test/mock to Maque. This solved a lot of our typical development use cases, but there were some limitations. These limitations became even more apparent once we started testing out our Proxy Rule feature during development.
The first big hurdle was that you had to change the URL endpoints within your app. A lot of apps, especially browser based ones, use relative pathing to define service endpoints. This required either a global change to the application for how endpoint urls were generated or you had to go in and explicitly change only the service calls you want to mock. In a lot of cases (particularly for bigger projects), it was worth the effort.
To get around changing code, there are some clever ways of configuring a front-end server (such as Apache or Nginx) to route only certain end-points to Maque using configuration files. This worked well for some projects, but as we see more and more cloud-based server technologies, less and less projects are using routing servers in the local development environment (they are often still used in prod, just not locally).
This means that how we interact with the local app server is changing. With technologies like Rails, you are hitting the app sever directly. Creating special routes to forward your requests to Maque kind of defeats the purpose in a lot of cases. Usually, we are trying to remove the server from the picture, not add more complexity to it.
Let me in!
The second major issue, and this became a blocker for Proxy Rules, is session authentication. When using cookie based authentication, such as a user being logged in, the cookie is bound to the host path and port. This becomes an a problem when you configure the app by changing the endpoint in your code.
For example, if I log in to my local app server with the host http://myapp.dev/ and then I proxy a rule through Maque using the default port localhost:5656, the browser will see these as different hosts and therefore strip any session cookies from the requests going to Maque. If you have a Proxy Rule configured for these requests, Maque would forwarded them to your web server BUT you no longer have a valid session and the requests would fail. This was seriously no bueno.
Route me right 'round
If you find yourself in any of these situations, then Project Proxy forwarding is for you! Instead of updating your app's endpoints or hacking at the local server you can configure your Maque Project to forward all requests to your web app. For example, I have an local app server that I am developing with bound to http://myapp.dev/, I can now configure my project to forward all requests to this server.
When I test the app, instead of going to my app server in the browser, I just point the browser to http://localhost:5656/. The browser will see all requests coming from the same hosts, will properly call any relative service paths and will also keep your session cookies for the requests. This sets us up to use Maque without having to touch our app code URL paths or the app server's routes.
Using this configuration, you can create Proxy Rules for any of the requests or you can fire up the Incoming Request Capture Wizard, capture the requests, create Rules, cache the responses and all the forwarded requests will work because the sessions are valid. In fact, if you really want to get crazy with the cheese whiz you can cache the entire site. The Proxy Rule cache can cache any file types, including images, CSS, JS, HTML, etc.
Make Proxy, not war
We are super excited about this new feature and how it helps streamline the Proxy Rule and Incoming Request Capture Wizard workflow. You should defiantly try it out and if you want to learn more about the Proxy Forward feature we have the official docs waiting for you!
~ The Maque Team ~












