dsyer
commented
7 years ago As @kakawait said, this is kind of scratching an itch I have at the minute, encountered while trying to build a demo for Spring Cloud Function. Serverless and functions mean the backend services get smaller and more numerous, so the pain is likely to be greater if anything. But a traditional microservice architecture clearly has the same tensions (the Xebia blog is quite good at describing the problem, if not really the solution).
I think there are a range of options, not all of which are as heavy architecturally as the existing tools in the node.js world referenced above (hence, for example, my question about whether you really needed a gateway and a layout service to be distinct physically). I also think the "component service" is a possible source of over-engineering complexity. It probably depends on your needs and the tools you use for the actual UI implementation.
I'm not really an expert on the UI side, so shadow DOM, react components, etc. are in my lexicon, but I can't really comment on the detail. IMO we would need a real UI expert to guide any concrete efforts here, and provide options that don't restrict the choices of front or back end technology (it's simply too diverse in the UI world for us to bet on any individual horses).
We would also need to keep a rein on anything that started to look too opinionated or too grandiose.
I have made some prototypes (sample apps) that demonstrate how you can use various different mechanisms to pull content through from a backend service.
-
It's super easy to set up a proxy in the gateway to mirror back end resources based on a naming convention. You could use Zuul, or spring-cloud-gateway, or just hand code an MVC endpoint (Spring 5 has a new ParsingPathMatcher that makes it a bit easier). You could use service discovery, or just configuration. I don't think we need to be prescriptive. The samples just do it in MVC with config for the backend URLs.
-
AngularJS has an
ng-includedirective which works really smoothly. All you need is for the gateway to proxy the fragment resources (to prevent issues with trust in the browser). I assume other front end frameworks can do the same thing. -
If you need server side templating as well (probably a good idea for the general case, but maybe not all apps), Spring Boot makes it easy to customize the template libraries to load templates from a custom source. Again you can use a naming convention and a proxy pattern to pull them from the backends. I tried it with Thymeleaf and Mustache and it was only a few lines of code for each in the gateway.
Sample code here: https://github.com/dsyer/frontend-microservices. Also see the Petflix sample (Thymeleaf template fragments from the backend): https://github.com/dsyer/petflix. That one is interesting because it is a real legacy monolith (Petclinic) with a new feature added as a microservice (pet videos).
kakawait
spencergibb
First at all that project seems really promising, far better then
Zuul 1version!Last day I was talking with @dsyer about designing/prototyping a kind of layout service / ui composition service (whatever the name) inspired from Zalando
Tailorproject (from global Mosaic project - Microservices for the Frontend).Goal of such service is to avoid getting a well designed and decoupled backend service used by a big monster monolith (SPA?) frontend. Each microservices could be responsible on their own frontend/ui fragments, layout service / ui composition service will be only responsible to aggregate every fragments using a base/master template and returns it.
I wanted to develop by myself a kind of closely inspired fork to Zalando
Tailorbut using Java + Spring 5 + Spring Boot 2.0 + Reactor. Though I really need such piece of service on my current stack, at start that project was also a good candidate for training myself to Spring 5 + Spring Boot 2.0 + Reactor.When I spoke that to @dsyer I also proposed an possible architecture based on Zalando one
And mine (Yes is a totally a clone of Zalando one :trollface: )(Attention is a prototype, any box is not necessary a dedicated services. Is more a logical view)
At this point, @dsyer ask me why I have separated gateway and layout service. I don't really have a clear answer but in my mind, only reasons was separation of concerns and resilience (if layout service get down, you can continue using
API). But I didn't think more.That why I open you an issue (is more a discussion, I'm not asking feature request) to
Existing alternative or similar project to Zalando
TailorHere some sources of inspirations about Microservices for Frontend topic: