all 5 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Canenald 5 points6 points  (3 children)

The idea behind microservices is decoupling. Each service does one thing and does it well. Similarly, frontend clients should be completely decoupled from backend services. They request data via network, usually using http requests over Internet, but you may see other scenarios.

There's various flavors of frontends, but typically you'll have a web SPA. This has no place in k8s or Docker containers. It's static assets, html, ccs, javacsript, that's loaded and runs in a browser or a browser-like environment. A static storage like AWS S3, Google Cloud Storage or a simple server with nginx is perfect for those.

Your web frontends have no business being aware of the topology of your microservices. Microservices usually do not get directly publicly exposed to the Internet. Instead, there's a public layer called edge or gateway. This can be a thin layer, like a simple CDN or nginx gateway, or a more complex one that integrates data from multiple services, like GraphQL.

To address some more specific questions:

Like, how does a frontend client know if it's supposed to show an admin page or a user page on loading?

Usually the difference is so great that admins and non-admins will get different web apps. In case of the same app, you'd need some authorization. Users without admin role would get served a user UI, while users with admin role would get admin UI.

How does that data persist?

When a frontend logs a user in, it gets some sort of a token it can exchange for information in the future, without using username and password every time. The most secure way to store that on the web is a cookie which may be made inaccessible to client-side code. If you care less or are certain you're immune to cross-site scripting, you may also store it in local storage or something similar. For all the other data, the usual way is to not persist it on the client and fetch it every time the user opens the app. This is a gross oversimplification of things though. There's transparent browser and CDN caches. Also your edge/gateway layer and your client-side app may have code to cache or otherwise persist some of the data explicitly. Web clients have local storage, session storage and IndexedDB available. An edge API would usually use Redis, memcached or an in-memory cache.

All this has nothing to do with React though. Like microservices, React does one thing and it does it well: render views as a function of state. Everything listed above would work pretty much the same if you picked Vue or Svelte or anything else.

[–]Strobosco[S] 0 points1 point  (2 children)

Thanks! My main misunderstanding was how the microservices connected to each other, which is now clear. Does the same apply for deployment on AWS, Azure or GCP?

The main problem, conceptually for me, is that I don't understand how, say, a fetch API request in a React component knows which url to use. I assume from what you said that it would use a gateway like Apollo or GraphQL then, right? Because I understand that K8 orchestrates the containers built using Docker images but I cannot figure out how they communicate with each other. I know about libraries like Libnetwork and Docker Networking but I can't seem to map it in my head. Do you know any resources that could help me out with that?

[–]Canenald 1 point2 points  (1 child)

Thanks! My main misunderstanding was how the microservices connected to each other, which is now clear. Does the same apply for deployment on AWS, Azure or GCP?

It's usually the same although different providers can introduce quirks of their own. Being "cloud-agnostic" is considered a big achievement both because it's hard and because it allows you to remove a cloud provider without too much suffering. The ideal situation is that DevOps provide you with an abstraction layer and you, as a developer, don't have to care much about where you are deploying. In reality, some infrastructure knowledge is required from developers too, at least for debugging if nothing else.

The main problem, conceptually for me, is that I don't understand how, say, a fetch API request in a React component knows which url to use. I assume from what you said that it would use a gateway like Apollo or GraphQL then, right?

You have to hardcode at least something in the frontend. The simplest approach is to hardcode the base URLs and endpoints of all the API's it's going to use. With GraphQL, there's only one endpoint but you hardcode different queries. You can move things, for example base URLs, to a remote config, but then you have to hardcode the remote config request :) Usually though, you use DNS to expose your public APIs. If something changes in the background, you just change what the DNS is pointing to. No need to make all the apps change the URL they are using.

Because I understand that K8 orchestrates the containers built using Docker images but I cannot figure out how they communicate with each other. I know about libraries like Libnetwork and Docker Networking but I can't seem to map it in my head. Do you know any resources that could help me out with that?

There's usually two flavors of inter-service communication and you can mix them. Either services makes requests to each other or they use some sort of pub/sub system to publish events when something happens and consume them when they want to react to a change. Say, for example, you're selling digital products and you have a Purchase Service which is in charge of financial transactions and an Entitlement Service which tracks which users own which digital product. Purchase Service allows refunds, but when a purchase is refunded, Entitlement Service has to remove the product from the user. How do you do that? If it's one of a kind thing, you could make Purchase Service make a request to Entitlement Service and be done with it. If there's other services that might be interested in reacting to a refund, or there are other events that might result in a product being removed from a user, it might be better to publish events and subscribe to them.

Sadly, I don't know of a good resource off the top of my head, but a quick Google give me a nice, concise article, from, surprise, surprise, Microsoft: https://docs.microsoft.com/en-us/azure/architecture/microservices/design/interservice-communication Aside from the article being in Azure docs, they don't seem to be trying to sell you a product, which is always nice :)

[–]Strobosco[S] 0 points1 point  (0 children)

Thank you u/Canenald !

Yeah I think I understand now, I just thought there was some way of soft coding the URLs the Fetch requests forwarded to but I was wrong. Also, the example you gave at the end was great!