Haxe for client/server applications
Companies are moving thier computation infrastructure to the cloud, focusing on providing APIs, allowing developers to integrate their services with other tools, for example Autodesk’s Forge Platform.
In addition, providing APIs often means providing clients, or client libraries to help interact with interrelated APIs.
The Haxe toolkit solves these problems, as well as providing numerous other advantages. I propose the Haxe toolkit fits extrememly well into an environment where services are built with Node.js, and clients in multiple languages are to interact with those services. Haxe also buffers your code from the often-changing technology landscape.
What is Haxe?
Currently, Haxe compiles to the following targets:
|Name||Kind||Static typing||Sys||Use Cases||Since|
|Flash||byte code||Yes||No||Games, Mobile||alpha (2005)|
|Neko||byte code||No||Yes||Web, CLI||alpha (2005)|
|ActionScript 3||source||Yes||No||Games, Mobile, API||1.12 (2007)|
|C++||source||Yes||Yes||Games, CLI, Mobile, Desktop||2.04 (2009)|
|Java||source||Yes||Yes||CLI, Mobile, Desktop||2.10 (2012)|
|C#||source||Yes||Yes||Mobile, Desktop||2.10 (2012)|
|Python||source||No||Yes||CLI, Web, Desktop||3.2 (2015)|
|Lua||source||No||Yes||Games, CLI, Web, Desktop||3.3 (2016)|
Although Haxe has many very useful language features, the most important features here are:
1) Build macros and automatic boilerplate code generation
Haxe’s macro system is very powerful, but a complete description of what they can do is beyond this scope of this blog.
I will focus on one aspect of macros: building compiled code from other code.
We have a server that provides an API:
This code is running in some Node.js server, and we would like to build a client that accesses this API.
With the haxe-json-rpc library we can automatically create client code (note that the haxe-json-rpc library is not complicated, and could easily be modified to support any transport mechanism such as protocol buffers or messagepack):
The ‘proxy’ class is generated at compile time. The methods that it calls
proxy.giveMeABanana(...) have all the function arguments checked, and if there is a mismatch or missing arguments, the code will not compile, and you will get a useful error.
This means as you add more API methods to your server, your client code is automatically generated and checked against the new API. There is no need to touch the client interface libraries.
Under the hood, the function calls are turned into JSON-RPC and pushed over the wire:
2) So many compile targets
Not only is the client code automatically generated, but it can be generated for multiple languages at the same time.
To do this, just add your compile target to the .hxml file, and you will see the code, or executables:
This demonstrates some of the power that the Haxe toolkit provides:
- Flexibility: write code for multiple platforms without losing the power of a compiler.
- Future proofing: as new platforms become available, the Haxe toolkit can target them.
- More robust code: compiler prevent simple errors, and make maintenance (e.g. refactoring) of large code bases much easier.