0

I've been grappling with this for a while and figured I would post here to get input.

I am a full stack engineer. I work on both front end and back end apps, where sometimes I have to create new microservices, or sometimes I need to create new front end clients to already-existing microservices.

The front ends of these microservices live in different clients: sometimes multiple internal websites and external websites. For example, say I have an internal company website called internal-site.com. This site has its own front end and back end (I use Java so it'd be a Spring app). My service (which is Dockerized and usually a mix of Spring Boot and Vert.x) might live on a Docker Swarm or Kubernetes cluster on a different domain. I've usually been inclined to build my front end inside of my internal-site.com's code base because that is where users will log in and use the form(s) that interact with the respective service. My front end is usually going to be a Vue or Angular JS app, that uses a Spring controller on its back end to then call a microservice. The good thing about that is that I don't need to deal with any CORS issues, which has proven to be a real pain in the past.

The problem there is that whenever I need to make code changes to the front end, I have to re-deploy the entire internal-site.com in order to ship those changes.

As a partial solution to this problem, my team has started moving front end apps out of internal-site.com and into their respective microservices. Front end apps are compiled in our microservices, and an end point in the service will serve the compiled JS to whatever client calls that end point. A view from the client internal-site.com will have a basic page (JSP for Java apps) and a <script> tag will call an endpoint on the back end of the client, that will then call the end point of the microservice and get the compiled JSP. With the back end of my client calling a microservice, we avoid CORS issues but still get the flexibility to deploy our front end apps without internal-site.com being a big dependency in their deployment.

But being that we still use a back end controller end point in our clients to call microservices, we are still somewhat dependent on the client if we need to make certain changes.

And of course, we have other sites that might have different front end frame works that use the service as well.

My overall question is, how should these types of situations be architected? Am I overthinking CORS, and just make my microservice calls directly from my front end apps to avoid having to make a client-side back end end point? Or do I leave as is? Or is there another way to architect this that I am not thinking of?

2
  • 1
    I´m a little bit confused. Are you using Micro-Frontends or do you have multiple frontend clients which access the same backend microservices?
    – Darem
    Nov 30 '21 at 14:45
  • @Darem I'm not sure the difference. I have front end clients that use the same back end microservice. Those clients (internal and external websites) have UI apps that are built using Vue or Angular. Some of those apps live in the internal and external websites, and some of them live in the services, but are used by the websites.
    – aCarella
    Nov 30 '21 at 15:59
2

To my mind you are mixing two different things. In my world the point of a microservice is that is has a well thought out interface. The protocol should allow for different use scenarios and simultaneous use from several applications, either other microservices or or other UI-s. The protocol would allow using any programming for access, any framework. So the microservice should contain and enforce business rules and only allow updates or changes according to the rules. "Illegal" updates should return an error. This also means that the microservice should support different UI frontends, but not in itself have any UI functions.

There is a different kind of "small" UI function which you describes that supplies a part of a page or similar in form of UI. This could of course be made available to other UI applications, but I would not call that a microservice.

So, my suggestion is as follows: start by defining an interface towards the microservice that has no UI content. Move everything that belongs to the UI part (the MVC model as example) to a different set of source code and check the interface of the microservice for useability. It is often good to do a bit of prototypen to get it right. Once the interface works, write and optimize the service component and the UI component in separate sets of source code.

The architecture then typically ends up as a a database component, a business microservice and one or more UI implementations. The communication outwards from the microservice is typically using a REST protocol in my world but you might have different setups preferred. We often end up relying on another microservice for supplying the "security" stuff and tokens.

1
  • I appreciate the answer, but to be completely honest most of this went over my head, as I was reading it from the perspective of the question(s) I posed. To simplify what I am asking; should the UI that gets and posts data to my microservices live in the clients that serve up the UI? Or should the UI be independent front end apps where the code base does not live in the clients which use them?
    – aCarella
    2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.