An idea for a Haxe-based web framework

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


typedef Task = {
    var text: String,
    var dueDate: Date
}

class TaskList extends Component {
    var tasks: Array<Task> = [];
    public function render() { // Client side rendered
        return <ul>
            for (task in tasks) {
                <li>${task.text}</li>
            }
        </ul>
    }
    public function componentDidMount() {
        this.tasks = @await Api.allTasks(); // Example using tink_await
    }
}

class Api {
    @:serverSide
    static public function allTasks(): Array<Task> {
        return /* Some database query */
    }
}

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?

1 Like

That is a good idea. :slight_smile: Macros are awesome, they can eliminate so much boilerplating.

tink_web does exactly that.

1 Like

Maybe you should fork the Ufront project and give it some new life! It works similar to what you describe but needs php7 support.

Ufront is obsolete and unmaintained, forget about it.

Kevin has been a very active contributor to Ufront in the past and I have found his code examples to be extremely helpful in the past, so our comments here should be understood in light of that.

@kevinresol So what is it do you think that makes Ufront non-salvageable? Security? Too big? My favorite parts was/is that it is useable with Javascript disabled, and that it uses an MVC model.

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.

3 Likes