What are your thoughts on this?
What do you need to create frontends with Spring? Do you even want to?
There are highly integrated ways like Vaadin and the lower-level approach by using HTMX and a template engine.
A huge advantage of the Hypermedia approach is that you don't need to build a general-purpose data API (htmx.org/splitting-your-apis) or use the Backend For Frontend pattern.
In a microservice environment, I would call this a Hypermedia Gateway.
Top comments (14)
I love HTMX, it's simple and productive, I can use any template engine with Spring Boot.
Also I created a plugin for Grails/Grace, it's easy to use.
github.com/grace-plugins/grace-htmx
github.com/grace-guides/gs-htmx-to...
In my company, we basically do the following:
I agree that there is a lot of complexity added when adding a JS frontend such as React. We need to expose an API, duplicate some validation rules, translate to/from Json, expose JWT tokens etc.
There is also the possibility to with backend templates to use React only for the highly interactive components cprohm.de/blog/htmx-react/
I did not try it out yet but maybe a topic worth exploring to create a nice react backend template integration.
For me I used Thymeleaf, but I stopped software development for four years and would like to start again.
For me I was satisfied using Thymeleaf, but I think todays market prefers React and Angular for front-end apps.
What I love about having the server always generating the HTML (based on its own state) is that it makes testing so much easier. (But the default of "let's use React/Angular/Vue" is still a very strong influence.)
I use both server-side rendering and frontend+internal API in my Spring Boot apps, depending on the use case. Sometimes just server-side, sometimes combined.
When there is just one client, when I have to use the frontend+API, what I do is to pack them together (using the frontend-maven-plugin) and include the frontend within the same springboot artifact, packed as a set of javascript bundles in the static directory, so I don't have to deploy a different artifact and play with cross-site requests or play the proxy-the-calls game. We use that, for example, to "embed" tiny self-contained apps in the middle of web pages without having to resort to portlets or similar proxies. Oh, and we chose Vue and so far, more or less happy with it.
The worst part, for me, is having to keep up to date with the JavaScript part, as updating the libraries and maintaining the JavaScript build&bundle side is a royal PITA. That ecosystem does not even have backwards compatibility in their dictionary! :D
Yeah, there could be a nice way to integrate an SPA into a server-side app for the highly interactive parts.
Yes the JavaScript fatigue of new libraries and modules is one of the main pain points.
Well your Gateway can be anything, it doen't have to be HTML/HTMX you can also do this with Json.
It is always a good approach to separate Frontend logic.
That's why I am a big fan of Hexagonal and creating an adapter purely for the frontend and have it's interactions limited to that adapter. That way I can really tune performance specific for the frontend.
Well that's kind of the point of the "Hypermedia" Gateway that it delivers HTML
First time I've heard about a hypermedia gateway, seems much like bff to me. What is the difference?
besides not 'talking api' with the front?
Well I think you can't really call it a BFF as it provides a uniform experience and it is not just a backend, but both combined.
I guess most tech stacks are driven by team preferences and existing knowledge, so they may end up using React while a few templates would have done it as well.
Yes but wait until the managers realize how much more productive engineers are with a full-stack application.
I think the popularity of htmx will help with that.