One of the most annoying things in web development is probably APIs behaving unexpectedly. Using a proper RESTful API usually avoids most of the problems, but we all know that sometimes inexperienced developers (and unfortunately, some seniors as well) mess it up.

Since Haxe can be used both for frontend and backend applications, I came up with the idea of using a common codebase for the two parts, which is compiled to two different applications, each with its own parts, that communicate with HTTP requests. But for the developer, the HTTP requests are abstracted away using macros. This way, api calls are type-checked, and we even get autocomplete! For example

On the backend app, allTasks automatically gets assigned a route (such as /api/all-tasks), the return value is automatically encoded when returned, as JSON or preferably some binary format to transport Haxe objects, using build macros. On the frontend, again using build macros, the function is converted into an HTTP request to that route which also decodes the data back to a Haxe object.

The major advantages are type checking, convenience, code reuse and rapid prototyping. This is of course just an idea (which I believe is possible to do with macros). There are definitely more things that need to be figured out such as caching, but I really like the idea. What do you guys think?

IMO it is too big and not well structured. It is very hard to maintain a big codebase where everything is interrelated. In contrast, tink_web is built on top of a number of self-contained libraries. The clear boundary between libraries make it more maintainable. Also the individual libraries (each solves a specific problem on its own) are highly reusable in other areas.