There have been few new problems shown to date, as a result of using this approach.
The one that makes itself most obvious is that server-side JavaScript is still young, and the plentiful libraries of code to do nearly anything one might want, readily available for PHP or ASP.net, are not yet available for JavaScript. This means that in order to do something as common as, say, sending an email message, requires extra work. With the backend running on App Engine, this would require accessing the Java API classes — not particularly difficult, but not as trivial as simply calling the mail() function of PHP [45]. Communicating with an external process would likely involve custom code that would not be required with the more mature environments.
Even now, though, Node.js is building a large library of code, easily require()’d (included) from custom code. As server-side JavaScript matures, it appears likely that
this problem may simply evaporate.
Recommendations
LIBERATED is a working implementation that is being used in a real, full-fledged application. There is ample related and continuation work that can be done, however.
First, it would be nice to determine exactly the impact of the compromises identified above. This would require, in many cases, implementing a parallel environment in a different language (or in multiple languages) to determine the impact of using the LIBERATED environment.
Additionally, there are a few obviously-missing pieces of the implementation, and some improvements that can be made.
Transactions
The biggest current deficiency in LIBERATED is its lack of support for database transactions. There are a number of ways to implement them from an API point of view, e.g., (a) a function call to begin a transaction followed by the requests to be issued within the transactions, followed by a function call to commit or roll back the transaction; (b) a function call to begin a transaction that takes as a parameter a function which issues all requests to be processed in the course of the transaction; etc. The database driver implications are a bit more complicated, though. In the simulation database driver, it would be trivial to save database changes in a parallel map until a transaction is committed. The App Engine datastore, on the other hand, does not make it trivial. Transactions for App Engine can only be applied to objects with a common ancestor as part of their entity type. This means that there must be more server-specific knowledge in the LIBERATED-based application’s schema. Some fair amount of thought will have to go into this.
SQL database driver
Relational databases, with their SQL interfaces for storing and querying for data, are in very common use. For LIBERATED to be more generally useful, a database driver which maps to one of the popular database servers such as MySQL should be developed.
Object relations
Relationships between objects in LIBERATED are ad hoc, maintained exclu-sively by the application. It is possible for a database driver (and database server) to impose more strict requirements on the database, e.g., with relations defined in a schema of a SQL-based relational database. That is entirely outside the scope of LIBERATED, though. It would be nice if some form of object relationship could be defined in the LIBERATED database abstraction, allowing for such things as automatic retrieval of related records.
Better browser-based persistent storage
The simulation database driver could be rewritten to use the HTML5 Indexed Database or some form of persistent storage other than a JavaScript map saved in its entirety to the localStorage object, as is currently done.
Additional operators in queries
Currently only “and” is supported as a query operator. Additional operators should be added.
Epilogue
The implementation of LIBERATED and the App Inventor Community Gallery have been described here as if LIBERATED was created first, and the Gallery project was written as a proof of concept. In fact, development on the App Inventor Community Gallery was the impetus to create LIBERATED.
I was the initial developer of the App Inventor Community Gallery code. Its frontend was qooxdoo-based, and the backend was originally written in Java and ran on App Engine. When we were preparing to bring new developers onto the devel-opment team, I created the beginnings of LIBERATED, with the simple intention of providing a JavaScript backend running versions of the remote procedure calls, rewritten from Java into JavaScript, to allow easier debugging for the new developers.
I then realized that the App Engine Java environment didn’t really require Java source code; rather it required Java .class files — a Java runtime environment. Rhino’s ability to run JavaScript code in any Java environment fulfilled that requirement.
Thus arose the concept of allowing complete debugging and testing in the browser, and fully-debugged and tested code to be moved to the production server environment.
References
[1] Web Technology Surveys, “Usage of server-side programming languages for websites.” http://w3techs.com/technologies/overview/programming_
language/all, September 2011.
[2] Web Technology Surveys, “Usage of client-side programming languages for websites.” http://w3techs.com/technologies/overview/client_side_
language/all, September 2011.
[3] Wikipedia, “Prototype-based programming.” http://en.wikipedia.org/wiki/
Prototype-based_programming.
[4] Google, “V8 javaScript Engine.” http://code.google.com/p/v8/.
[5] Joyent, “Node.” http://github.com/joyent/node/wiki.
[6] Mozilla, “SpiderMonkey.” http://developer.mozilla.org/en/SpiderMonkey.
[7] Pepijn de Vos, “JS Server Benchmark: Node.js & Rhino.” http://pepijndevos.
nl/js-server-benchmark-nodejs-rhino/, August 2010.
[8] Mozilla, “Rhino.” http://www.mozilla.org/rhino.
[9] R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, Irvine, California, 2000.
[10] R. Tomayko, “How I Explained REST to My Wife.” http://tomayko.com/
writings/rest-to-my-wife, Dec. 2004.
[11] J. White, “High-level framework for network-based resource sharing.” RFC 707, Jan. 1976.
[12] B. J. Nelson, “Remote Procedure Call,” Tech. Rep. CSL-81-9, Xerox Palo Alto Research Center, May 1981.
[13] A. D. Birrell and B. J. Nelson, “Implementing remote procedure calls,” ACM Trans. Comput. Syst., vol. 2, pp. 39–59, February 1984.
[14] D. Winer, “XML-RPC Specification.” http://www.xmlrpc.com/spec, June 1999.
[15] “Extensible Markup Language (XML) 1.0 (Second Edition).” http://www.w3.
org/TR/2000/REC-xml-20001006, Oct. 2000.
[16] D. Crockford, “The application/json Media Type for JavaScript Object Notation (JSON).” RFC 4627 (Informational), July 2006.
[17] JSON-RPC Working Group, “JSON-RPC 2.0 specification.” http://jsonrpc.
org/spec.html, Mar. 2010.
[18] S. Vinoski, “Convenience Over Correctness,” IEEE Internet Computing, vol. 12, pp. 89–92, July 2008.
[19] D. Benjamin, “Ten things that XML-RPC does... that REST leaves unspecified.” http://ramenlabs.com/2008/02/17/
ten-things-that-xml-rpc-does-that-rest-leaves-unspecified/, Feb.
2008.
[20] E. Newcomer, “Abstraction and control in REST vs RPC.” http://blogs.iona.
com/newcomer/archives/000572.html, July 2008.
[21] K. Zyp, “REST and RPC Relationship.” http://www.sitepen.com/blog/2008/
03/25/rest-and-rpc-relationship/, Mar. 2008.
[22] T. Ewald, “Three reasons that REST is not RPC.” http://www.
pluralsight-training.net/community/blogs/tewald/archive/2007/
04/28/47067.aspx, Apr. 2007.
[23] UnixSpace, “Database models.” http://unixspace.com/context/databases.
html.
[24] E. F. Codd, “A relational model of data for large shared data banks,” Commun.
ACM, vol. 13, pp. 377–387, June 1970.
[25] S. Ambler, “The Object-Relational Impedance Mismatch.” http://www.
agiledata.org/essays/impedanceMismatch.html.
[26] “qooxdoo – About.” http://qooxdoo.org.
[27] D. Crockford and C. Douglas, JavaScript: The Good Parts. O’Reilly Media, illustrated edition ed., Dec. 2008.
[28] “What Is Google App Engine.” http://code.google.com/appengine/docs/
whatisgoogleappengine.html.
[29] J. tzay Yang, J. long Huang, F. jian Wang, William, and C. Chu, “Constructing an object-oriented architecture for web application testing,” Journal of Information Science and Engineering, vol. 18, pp. 59–84, 2002.
[30] S. Elbaum, S. Karre, and G. Rothermel, “Improving web application testing with user session data,” in Proceedings of the 25th International Conference on Software Engineering, ICSE ’03, (Washington, DC, USA), pp. 49–59, IEEE Computer Society, 2003.
[31] E. E. Aftandilian and S. Z. Guyer, “Gc assertions: using the garbage collector to check heap properties,” in Proceedings of the 2009 ACM SIGPLAN conference on Programming language design and implementation, PLDI ’09, (New York, NY, USA), pp. 235–244, ACM, 2009.
[32] E. Aftandilian, S. Z. Guyer, M. T. Vechev, and E. Yahav, “Asynchronous asser-tions,” in OOPSLA, pp. 275–288, 2011.
[33] Wikipedia, “Comparison of server-side JavaScript solutions.” http://en.
wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions.
[34] W. Team, “SquirrelFish Extreme.” http://www.webkit.org/blog/214/
introducing-squirrelfish-extreme/.
[35] W3C, “Web SQL Database.” http://dev.w3.org/html5/webdatabase/.
[36] W3C, “Indexed Database API.” http://dvcs.w3.org/hg/IndexedDB/
raw-file/tip/Overview.html.
[37] A. Ranganathan and S. Wilsher, “An early walk-through of IndexedDB.” http:
//hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/, June 2010.
[38] J. Rees and B. Donald, “Program mobile robots in scheme,” 1992.
[39] “Google Web Toolkit Overview.” http://code.google.com/webtoolkit/
overview.html.
[40] L. Bak, “Dart: a language for structured web programming,” Oct. 2011.
[41] D. Kellogg, “Plain Old Webserver.” http://davidkellogg.com/wiki/Main_
Page.
[42] A. S. Foundation, “The Apache CouchDB Project.” http://couchdb.apache.
org/.
[43] M. Rogers, “PouchDB (Portable CouchDB JavaScript implementation).” https:
//github.com/mikeal/pouchdb.
[44] 4D, “Wakanda JS.everywhere().” http://www.wakanda.org/features.
[45] “PHP – Send mail.” http://www.php.net/manual/en/function.mail.php.