Quarkus + Renarde + Quinoa + htmx = 🤙

[TeHMoroS]

Hi. I've been continuing with the HDA-style approach using Quarkus (with Renarde), Quinoa and Htmx. My initial opinion is that Quinoa is quite SPA-centered and very hard to use for MPA or HDA apps.

This is going to be quite long, so here's a TL;DR: Quinoa could use an option for specifing requests that's it's allowed to redirect or the ignoring option could be regexp-based, otherwise it's unusable for developing MPA/HDA-style apps.

Long version:

After resolving the CSS purge issue with templates being outside Quinoas graps (#61) by a workaround (disable purge in dev mode), I've been hitting other road blocks, but let's get the context straight first.

When creating an MPA (classic multipage application) or an HDA (hypermedia-driven application, specifically with Htmx returning ready parts of the HTML), one often uses a configuration where back-end code handles templates (Qute in this case) and also has an additional side-pipeline for handling assets (JS, CSS, images, fonts, etc.) which is Node-based - mostly the aftermath of SPAs going mainstream and focusing all of the attention. This pipeline is almost always on this - a asset processing pipeline, not a fully-fledged UI app.

It's not really that exotic: Laravel has a whole module just for that (Mix), likewise Symfony (Encore). Quinoa on the other hand is mostly SPA-focused which bascially makes it imposible for using with a asset processing pipeline. My experiences with this so far were:

• CSS purging problems due to templates being outside of the UI folder (Option for specifying additional watch locations #61 - worked around);
• unable to utilize the Quinoas dev server, due to the fact of lacking a fine-grained configuration - this is a longer issue, which I'm going to go into detail below;
• without the dev server, one is stuck with Quinoa running npm build all the time, which while being errorless, is very slow (imagine fine-tuning your UI code/CSS/whatever with small, rapid changes and being forced to wait a few seconds on every refresh - unusable in the long run).

Now, let's look at the dev server. It's a nice solution for an app that has all web resources (HTML, JS, CSS, other) on Quinoas side. Just redirect the requests to the UI dev server, ignore the REST API ones and done. This. This is very SPA-centric. It's basically unusable for a MPA-style development (hence HDA-style also, which is very similar, yet results in a hybrid SPA/MPA-like app).

A two problems here:

1. Dev server requires, well, a UI dev server on the other side. For MPA/HDA it might not be the case. The whole process can be a simple pipeline for processing assets with a watcher triggering the build on change and outputing the resources in a target location. Quinoa goes either the "copy resources path" or "redirect requests path". Nothing in between, like: "watch the target dir and copy resources on change, because there's a second build pipeline building those assets".
2. After working the first problem around by actually providing a simple web server for Quinoa to redirect to, there comes the second problem: no fine-grained request control. When the UI server is provided, Quinoa redirects the root request ("/") to the UI server. Not what one wants for the MPA/HDA, where the templates (and the root request) are being processed by the back-end. Of course there is an option for ignoring requests based on prefix, but try to use the root request ("/") here - you disable redirecting altogether. A simple regexp-based approach would solve the problem here. Either that or to provide options not only for ignoring requests, but for allowing also (e.g. allow prefixes like /images, /css, /fonts - for MPAs/HDAa you'll probably have only a few of those).

The above forces us to use the npm build style, which with constant full rebuilds (Webpack already takes around 4-5s at this point, and we're getting started), makes us thinking of dropping Quinoa in favor of hand-feeding src/main/resources/META-INF/resources by Webpack (which requires hand-crafted Gradle, Git and Webpack config and launching two dev mode tools separately). Resolving the second problem (by regexp or additional "allow requests" option) would make Quinoa fit for making MPA/HDA apps with only a bit of additional configuration.

[ia3andy]

It would be nice to create a repository with this POC, then we could fork Quinoa to have something fully compatible and see if it's worth merging? WDYT?

[TeHMoroS]

Actually I'm in the middle of making a starter project for a "Htmx+Webpack on Quarkus+Renarde+Quinoa" (I went with Renarde after your suggestion and a bit of experimentation). I can prepare an example repo with both configs mentioned: npm build-based (long refresh problem) and npm start-based (request control problem). :)

[ia3andy]

That sounds prefect, just make the "request control" problem one, I will create a Quinoa fork which makes it work and see if it sustainable ;-)

[ia3andy]

Also I remember @phillip-kruger showing me a Java library able to deal with assets (css, sass, fonts, ...) we should also see if NodeJs is the best solution forward.

[TeHMoroS]

Before the SPA boom (when we handled UIs with Struts, Tapestry, Wicket, etc.), we had solutions like Yahoo's YUI Compressor, but that was only a compressor at best, not a bundler or optimizer. On the other hand, the Node ecosystem evolved here very nicely, up to a point where not only one has a compressor or a bundler, but also optimization via tree shaking, dead code elimination, CSS purging, image optimizing, etc. I've tried searching for something even a bit similar in the Java ecosystem, but turned up empty-handed, so the library you mentioned might be very interesting.

Other than that, with Quinoa managing and integrating Node into Quarkus' app development workflow, it creates a nice development experience: no excessive configration (the configs for everything are almost standard) and a single point of dev mode launch (instead of managing separately). You just need Java, Node and your project code and (with a little help from the Maven/Gradle wrapper) you're basically set to build the app.

[phillip-kruger]

https://github.com/wro4j/wro4j

[ia3andy]

cc @maxandersen @FroMage

[TeHMoroS]

@ia3andy, here's a simple recreation of the project structure: https://github.com/TeHMoroS/quinoa-request-control-discussion

It's a simple HDA-style approach with Htmx and with Quarkus+Renarde as a back-end and template source. Basically a very stripped down version of what we're using (Gradle-based).

If you don't want to read the ton of "rationale" behind this, then just skip to the Request control issue at the bottom of the README. :P

[ia3andy]

@TeHMoroS Do you have zulip? https://quarkusio.zulipchat.com/

[TeHMoroS]

@ia3andy I do now. :)

[FroMage]

I'm not sure I understand why we're not simply attempting to serve the request and if it's not served or there's a 404, say, we then redirect to the UI server?

This would allow you to hit the Renarde endpoints (and even static assets), and if nothing matches, then forward to the UI server, with zero config (paths) required.

[ia3andy]

@ia3andy Works like a charm. 😁

I've removed the placeholder index.html and changed the check path to one of the generated assets.

The amount of config was minimal:

  quinoa:
    dev-server:
      port: 9000
      check-path: /main.js
      logs: true

main.js is the main JavaScript asset being generated, but the 30s timeout seems plenty enough, for the time being. IF it doesn't, I'll switch to something that gets generated faster.

Anyway, I went through the code changes (I'm also trying to learn what and how), build it locally with tests enabled (if the default is the full suite, then it was the full suite). Everything seems to be running well. 😄 So, basically, while still having Quinoa SPA-focused, with this, it's now possible to shift that focus to a MPA/HDA-style app (still powered by Node's ecosystem on the asset part) with minimum effort.

I will perform a 1.1.0 release tomorrow with this patch.

[ia3andy]

When released, I will prepare a blog post and some quickstart repo (and mention your name/handle in it if that sounds good to you)

[TeHMoroS]

@ia3andy Awesome. Looking forward to it. 😄

and mention your name/handle in it if that sounds good to you

Sounds great and... I guess now the pressure's on me to complete that starter project. 😉

[ia3andy]

Sounds great and... I guess now the pressure's on me to complete that starter project. 😉

@TeHMoroS for the starter could you use Maven as package manager and also make me admin on the repo please.

[TeHMoroS]

Ok, I'll use Maven. I'll also add you to the repo as soon as it's up.

[ia3andy]

Here are a lot of places we need to advertise about Quarkus + Quinoa/HTMX once it's ready: https://github.com/rajasegar/awesome-htmx

[ia3andy]

@TeHMoroS it would be nice if you would publish even if not complete, then this becomes open-source and you/we can iterate on it ;-)

[derkoe]

@TeHMoroS then you can use my code as a base for your TodoMVC app - I've licensed it under MIT

[TeHMoroS]

@ia3andy Sorry for the delay (I had some personal issues to address). I've created the initial started project: https://github.com/TeHMoroS/quarkus-renarde-quinoa-htmx-starter

@derkoe Thank you. I'll be building the TodoMVN based on some of your code then. :)

[ia3andy]

Thanks @TeHMoroS, this looks good! I will have a closer look next week ;-)

[TeHMoroS]

Ok. I need to catch up with a few things at the moment, but I'll also try to put the TodoMVC up there next week. That should make it complete.

[ia3andy]

I opened a thread to discuss this on Quarkus core repo: quarkusio/quarkus#27525

[melloware]

There is now a custom Quarkus Extension called Web Bundler to accomplish exactly this: https://github.com/quarkiverse/quarkus-web-bundler