Why FastCGI a.k.a Why Not Reverse Proxy? I’ve previously written about why I prefer reverse proxying to FastCGI. I still believe all those points, however there are certain Seaside deployment situations where FastCGI is currently preferable to reverse proxying. If you are deploying your Seaside application to run on Gemstone’s GLASS then you should give FastCGI serious consideration. The current swazoo adapter that you use when proxying to GLASS is nowhere near as battle tested as the FastCGI adapter.…

READ THIS ARTICLE

Why Reverse Proxy a.k.a Why Not FastCGI? Transparency. FastCGI setups are opaque. You can’t easily test all aspects of it. Unless you write your own FastCGI client, debugging configuration problems can be very difficult. Lets imagine for a moment that are trying to debug a problem with your application– the issue might be in the front end server or it might be in the Seaside application server. When you are using FastCGI, all your interactions with your application server are routed through the front end server which acts as a client for you.…

READ THIS ARTICLE

So, you are humming along developing your GLASS hosted Seaside application. If you are following the proscribed development path, your application is running in Pharo and you’ve started porting it to GLASS when a problem arises: Your application needs to make calls out to a secure web service (merchant processor etc) but, GLASS doesn’t have a native https client. The Pharo cryptography package implements an https client which you could port to Gemstone, but the process model it uses doesn’t map nicely and you have better things to do with your time.…

READ THIS ARTICLE