Proxy or no proxy for your API? That’s not the question. One of the common debates when setting up an API management system is whether to proxy your traffic in some way before it reaches your application stack – and there are pros and cons to different architectures. however that’s not the goal of this post.

If a proxy based architecture fits your requirements the next question remaining is what proxy should we put in place? Yes, there are options, in fact there are many. On one hand there are the closed proprietary proxies offered by different vendors. On the other hand there are open-source proxies like Varnish, Squid, Apache, Nginx, etc.

Proxies are basic components of today’s technological stack, just like web servers or load balancers. At 3scale we believe that is better to integrate, extend and support open source solutions rather than reinventing the wheel and charge for it. Is your API using a proprietary web server? Probably not. Apache and Nginx alone have more than 75% market share as of 2012. Why proxies should be different?

Open source is not a matter of licence costs, let alone a matter of being cool. Is a matter of production ready software, proven high-performance, reliability, community support, plenty of documentation and examples and public scrutiny to detect and fix security vulnerabilities, etc.

So, which open source proxy should you look at? There is no right or wrong answer here. It depends on your current stack, on the expertise on a particular framework, it even depends on personal taste. What is important is that there are terrific solution readily available.  Squid is one, the proxy modules for both Apache and Nginx are also very interesting specially if you are already using Apache or Nginx for your web server. But perhaps the most famous one is Varnish, never heard of it? Time to get updated.

Varnish is part of the infrastructure at power-houses such as Twitter, Facebook, Heroku, LinkedIn.  But proxy/caching is not a used widely, also beyond the biggest sites;  Softonic, Peoplebrowsr, Magento among many others also use it to power-up their backend.

According to Varnish’s web page,

Varnish is a web application accelerator. You install it in front of your web application and it will speed it up significantly.

This one-liner on their main page does not make justice on how powerful Varnish is. Architecturally Varnish is a proxy that stays in front on your HTTP stack (roughly speaking, the tech stack that ends up serving web pages and/or API requests).

Varnish usually is placed in front of a web server like Apache, Nginx, Tomcat, IIS, Thin, etc. Whatever web server you use, you can stick a Varnish in front of it like that

After the initial setup, which takes minutes to have up and running, Varnish will cache the heck out of your application, whether it is web pages or API calls. The caching layer is extremely configurable and can be used to serve both write or read heavy workloads. The must read blog High Scalability has a recent entry on Varnish that says it all, and better.

Can we use varnish to scale our API? Absolutely, in fact, you should. API requests are web content and as long as you don’t have a write only API the benefits of an open, well maintained and secure proxy + caching layer will save you on the load of your servers at the expense of less revenue for Amazon/Rackspace/Softlayer.

Our API does not have scalability problems as of today, we are still low on traffic. True, you don’t have to use it, but serving a request from the varnish cache can be order of magnitude faster than if the API request has to go all the way down to your application code. Latency matters, and you don’t want your API to be “slowish”.

So if your API needs a proxy, can you use 3scale? Absolutely, if your choice of proxy is Varnish you only have to add the new 3scale module for it, available on github. With the 3scale module for Varnish basically we are adding the 3scale management and control layer to our API at the level of the proxy.

Once the 3scale varnish module is installed Varnish will check against 3scale for the validity of the API request. If positive, Varnish will serve the result from its cache or fetch the data from your origin server, finally Varnish will report to 3scale to maintain the consistent state and real-time analytics. Needless to say that the connection between your local Varnish proxy and 3scale’s backend can be done asynchronously so that latency is kept at a minimum, again thanks to Varnish’s caching abilities.

In follow up posts we will give a step by step guide on how to integrate your API with Varnish. Also, we will dig further on the powerful VCL (Varnish configuration language) and its third-party modules support. Besides making it extremely easy to integrate your API with external services like 3scale. Varnish can also be helpful in domain specific tasks like basic transformation and security.

Stay tuned.