Raxx - Interface for HTTP webservers, frameworks and clients



It seems like it would be cool to integrate with my Vampyre package when it’s done for even faster templates :smile:


Have a link?


Plugs are not really compile time. The Plug.Builder DSL is compile-time but not Plug themselves. For example, if you need to dynamically initialize a Plug, you can easily invoke that Plug at runtime. If you want to have a builder that works fully at runtime, that should be possible too.

EDIT: Although we should probably move this discussion elsewhere so we don’t sidetrack the Raxx discussion.


It’s an experimental library I’m writing. You can find a description (and link to the repo here). But on further thought, It might be too tailored to Plug applications. But the main template compiler could be used with Raxx. I’ll look into it when I’ve completed the Phoenix implementation.


@tmbb It looks interesting. I need to spend some more time to dive in to the entirety of that thread I think.

(although Vampyre depends on phoneix_html for some utilities for escaping HTML and other things).

I don’t know if https://github.com/CrowdHailer/eex_html might be of use to use. I pulled out some general HTML things there because I was only using a fraction of phoenix_html.


The main optimization is the fact that I turn some complex HTML widgets into macros that are aggressively optimized at compile-time. You don’t seem to have any HTML helpers, so speed benefits might be minimal… For a highly dynamic template, like one that uses form_for/4 I get impressive speed benefits, but if the “Raxx way” is to write all your HTML explicitly (no HTML helpers), then there might be no benefits.


No I just meant that EExHTML might be a useful dependency, instead of phoenix_html, as it contains just the HTML utilities. Are you relying on phoenix_html’s implementation of form_for?

There is no “Raxx way”. But in my current work I don’t make much use of form helpers


Middleware added, supports compile-time or run-time configuration

Raxx now contains the following:

  • Raxx.Middleware behaviour for implementing middleware
  • Raxx.Stack composing middleware and servers/controllers/actions
  • Raxx.Router apply middleware to specific routes in an application


0.17.4 Dialyzer warnings in Raxx.Router fixed.

The new middleware capable router module generated code that resulted in dialyzer warnings when using the section macro.

Thanks to @Adzz for raising this issue.


Roadmap to 1.0

The next goal for Raxx is to make a 1.0 release. This reflects the success that has been had using it in production. Once the tasks on this tracking issue are finished a 1.0 release should follow.


0.17.5 released

Extracts the Raxx.Logger module to it’s own project.

Add {:raxx_logger, "~> 0.1.0} to you mix.exs file for a backwards compatible update


0.17.6 Add shared context to middleware to handle more use-cases.

Raxx.Context added

A structured place to keep information between middleware and actions.
For example an authentication middleware can add user data to the context.

See documentation

Raxx.View and Raxx.Layout extracted

Extracts the Raxx.View and Raxx.Layout module to it’s own project.

Add {:raxx_view "~> 0.1.0} to you mix.exs file for a backwards compatible update


Core library streamlined

From 0.18.0 the core raxx library is focusing on being an interface.
This is in preparation for a stable 1.0 release. This focus allows extensions such as session and cores can continue to be iterated upon.

When upgrading it is advised to upgrade to 0.17.6 and handle warnings before moving to 0.18.0

See CHANGELOG for details