Programming Opa: Web Development, Reimagined
MLstate's Opa streamlines Web app development with a single language for client and server, but the bright promise is not without pitfalls
Wed, February 01, 2012
InfoWorld — Building a Web application today means using a variety of different software technologies, each executing in a different domain. JavaScript, HTML, and CSS in the browser; PHP, Python, Java, Ruby, or the like on the server; MySQL, PostgreSQL, SQL Server, MongoDB, or any of a growing list of database servers as your persistent storage back-end. With Opa, an open source Web development technology from the French company MLstate, building a Web application tomorrow could be much more straightforward -- and safer.
Not only are today's diverse technologies difficult to master, they complicate security. Each boundary between the different domains requires a communication mechanism that passes data between those technologies. And each of these communication conduits can be exploited, as attackers can intercept data or inject damaging information.
[ Also on InfoWorld: 10 programming languages that could shake up IT | 11 programming trends to watch | 12 programming mistakes to avoid | Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. ]
Opa tackles these issues from a fresh angle. With Opa, you write your Web application as though it were a single-tier program, and the compiler handles the knotty details of partitioning your program and deploying the resulting components to their proper domains. The compiler also builds the communication infrastructure among application components, and that infrastructure is invisibly managed by the runtime. The security weaknesses inherent in today's Web applications are virtually eliminated.
This apparent magic is possible because Opa is not just a Web framework, but an entirely new language, engineered specifically to let you create Web applications as though they were monolithic applications. You program the entire application in the Opa language; you don't soil your hands with JavaScript or SQL. Opa creates the client code, the server code, and the database code under the covers. (Actually, Opa doesn't soil its hands with SQL, either. Its internal database is not SQL-based.)
In addition, an Opa application's monolithic structure is not merely conceptual. All the pieces of your Web application -- the HTML files, JavaScript source, image files, CSS files, and so on -- that would ordinarily be placed in separate directories are bundled by the compiler into a single executable. This makes deployment simple; you only need copy one executable file to the deployment destination.
It also improves security significantly. Your code thinks that the application's directories and files are actual directories and files out on a file system somewhere. But, from the perspective of the outside world, the files and directories aren't there. Someone who manages to access your Web application's home directory cannot manipulate the constituent HTML, CSS, or JavaScript files because they simply don't exist. In addition, the Opa compiler runs a security audit as it builds your application, minimizing the likelihood that you might have inadvertently introduced a client-to-client or client-to-server code injection security weakness. The compiler will not allow foreign code to be inserted into the execution flow at runtime.
