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.

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.

Sounds wonderful, but doesn’t this all-in-one structure complicate development? Suppose that, upon executing your application, you discover that you’ve put the wrong PNG file on one of the Web pages. If everything is stuffed into a single executable, you have to replace that PNG file, then rebuild the whole project, right? Happily, no. Simply execute your application with one of Opa’s debug options enabled, and Opa creates an “opa-debug” directory — a directory that contains all of the application’s modifiable files. Replace the incorrect PNG file with the correct version — which you can do even as the application executes — and Opa will use the copy in the “opa-debug” directory, rather than the version embedded in the application.

Inside Opa
Opa is written in OCaml, which has influenced the design of the Opa language. Programmers from imperative or object-oriented language backgrounds will face a steep learning curve and will need to grapple with new terminology. For example, a sum type is an entity that, depending on the execution path, can have different values and serves roughly the function of a union in C/C++. The term “pattern matching” refers to the mechanism used in Opa’s branching structures, which are roughly analogous to switch() statements, but far more powerful. And all this is on top of Opa’s demand that you jettison the habit of explicitly considering which part of an application executes in the browser and which part executes on the server.

Related Posts:


Comments are closed.