WCGI combines the newest innovations with the technology of the old school. To what end? CGI is dead. Long live WCGI!

CGI (Common Gateway Interface) was a way for web servers and server-side programs to interact simply by taking a request over STDIN and returning a response over STDOUT. The protocol, however was inefficient, because it required a new process to be respawned each time a page was served. As such it was superseded by technologies which were better, faster, more secure, with better integration with the web server.

One such was FastCGI which was introduced as a middle ground between the PHP Apache Module and the CGI application. It allowed scripts to be executed by an interpreter outside of the web server and included the security benefits of CGI without any of the inefficiencies of CGI. For an example in Java, see Servlets.

Now enter the brave new world of WebAssembly. In "Spin Brings WebAssembly To The Cloud" we found that:

First, WebAssembly was touted as a runtime that would be embedded into every major web browser in order to write code in any language that could be compiled to its bytecode format. Because of that, the popular browsers would be able to execute not just JavaScript but also compiled binaries, hence the second property that was attached to it - the Javascript killer.

As things progressed, both of those assumptions were debunked. WebAssembly has broken loose of the browser's constraints and can be used for running Microservices or serveless functions or even run Wasm binaries on the command line so that even cross-platform CLI applications can be developed. So rather than kill JavaScript it might even interoperate with it.

Spin provides the interfaces for writing WebAssembly modules that can do things like answer HTTP requests. With Spin you reduce the overhead of microservices by factoring out the web server (replaced by a WAGI server) and writing out HTTP handlers in whatever language we want (Rust, C, JavaScript, Python, etc), which are then compiled to WebAssembly.

And there it is - WAGI - WebAssembly Gateway Interface. The WAGI server, provides a web server that answers requests. On each request, it loads the appropriate WebAssembly module, translates the HTTP request to a CGI request, and then runs the module. All of the threading and state management is handled in the WAGI server, while a WAGI WebAssembly module just has to handle a single request.

The new kid on the block is now WCGI as in WebAssembly + CGI. WCGI represents a refined approach to server-side development, integrating the flexibility, security, and performance of WebAssembly. WCGI was found by Wasmer which when venturing into serverless solutions, faced a crucial question -should they create their own framework and risk locking developers into a walled garden, or should they adopt an open standard that allows them to utilize existing code?

It turns out that WebAssembly+CGI was the most sane attempt, since you:

• Can invoke wasm modules instead of native executables
  
  
• Can reuse your existing CGI applications by compiling them to WASI (AssemblyScript, C, C++, Go, PHP, Python, . . . )
  
  
• Ship ultra-small packages that will only contain your business logic and static assets, no HTTP stack or bulky Docker containers
  
  
• Have complete sandboxed execution: WebAssembly code runs in a sandbox, with one isolated instance per request.

But WAGI does sound a lot like WCGI, doesn't it ? In essense both are means of writing and executing HTTP response handlers as WebAssembly modules.

They are two very similar protocols, one founded by Wasmer and the other by Deis Labs. Which one will prevail only time can show. Nevertheless both WCGI and WAGI at the time are compatible.

In conclusion, IT although an incubator for innovative technologies, it has the tendency of going in circles reviving old technologies and bringing them back to life, for instance Microservices to Monolith, or SPA to SSR. This is another case where the simplicity of the 'old' technology is so insurmountable that is hard to resist.

There's already a Rust and PHP template for for creating a WCGI-compatible package that can be published to WAPM, as well as a WCGI WordPress Demo. Links below.

More Information

Announcing WCGI: WebAssembly + CGI
WCGI Template for Rust

WCGI WordPress Demo

WCGI Template for PHP 

Related Articles

Spin Brings WebAssembly To The Cloud

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info