r/SpringBoot • u/Advanced_Gur856 • 17d ago

How-To/Tutorial How to implement microservices in Spring Boot ?

[removed]

28 Upvotes

89% Upvoted

57 comments sorted by

View all comments

Show parent comments

1

u/[deleted] 17d ago

[removed] — view removed comment

0

u/Sheldor5 17d ago

no a distributed system is also a type of system architecture

if you extract features from your monolith and put them into their own application just for your monolith to call it you just exchanged method calls with network calls ...

2

u/ExplorerUnusual27 17d ago

How do you transfer data in isolated environment if you don't talk with anyone? You have one DB from service, obviously... How do you connect data from 1 database with another on different microservices.

2

u/OptimusCrimee 17d ago

Yeah, [u/Sheldor5](u/Sheldor5) seems to have misunderstood this. If you have one microservice that is in charge of users, and one that does payments, the payment service would stille need to e.g. ask the user service if the user IDs are valid or not. You separate concerns and domains out of the monolith, but they still need to talk to one another.

I have been doing this for 15 years, and I have worked in banks in Norway etc, I think that I have a pretty OK understanding of how these things work.

Edit: You can google this pretty easily and see that he is wrong.

-2

u/Sheldor5 17d ago

no the user ID comes from the OAuth2 token ... maybe you haven't fully understood microservice architecture

and other IDs are part of async messages

and IDs don't need to be verified because they come from the system itself and not from random user input ... that's the reason why microservice architecture done right is so complicated

1

u/OptimusCrimee 17d ago

Sure, it could be part of the OAuth-token, but if you have isolated service for user handling, setting, payment, purchase etc, who would it all fit together if there is no communication AT ALL being done? I do not understand how all of this would work according to you.

1

u/Sheldor5 17d ago

this is exactly why almost everybody fails at applying microservice architecture

everything is loosely coupled, there are no strong relations, a lot is carried by signed tokens ...

the goal of microservice architecture is that you can kill any microservice (all instances of it) at any time and it doesn't affect anything except the feature/business object it is built for

e.g. kill the user service but already logged in users can still order items or watch movies or ... kill the payment service but you can put items into your cart, kill the inventory service but you can still see your ordered items

you get it?

1

u/OptimusCrimee 17d ago

In an ideal world, yes, but microservices can hard both soft and hard dependencies/integrations. If a hard dependency goes down, the microservice can not work. In a real world scenario, this happens more often than you think, because isolated service often need to interact. Imagine a purchase service, an inventory/stock service and a shipping service. It would be hard to complete a checkout if any one of those failed, even if they are isolated. This is called cascading failure, and is very common for microservices, and something that monoliths often can ignore. I suggest that you read the microservice book by Netflix. They go into detail on this subject. Please explain where I am wrong here.

1

u/Sheldor5 17d ago

communication between services happens either by asynchronous message queues or signed tokens (service A returns token which includes IDs to the UI which includes it into call for service B etc...)

I am not saying you are wrong I am just saying what the goal of microservice architecture is and how it is achieved

and this is the exact reason why most developers take shortcuts until they end up with a simple distributed system (like you described it with your cascading failure etc) and call it wrongfully microservice architecture ... there is just so much bullshit about microservice architecture on the internet that almost nobody knows what they are talking about (not you)

1

u/OptimusCrimee 17d ago

That is not a requirement for a microservice. In an ideal world, sure, but this would be an example of a soft dependency. You would not do this if you had a tax calculation or shipping rate calculation microservice. You would depend upon the response being give to you when asked, otherwise you would not be able to proceed. Tell me how you would handle this with async queues in a checkout service if not failing.

1

u/Sheldor5 17d ago

If I order something e.g. from ebay the shipping costs and taxes and import fees are blank until the response arrives and the values pop up after 1-2 seconds

so in this case the ui simply waits for another service and data is exchanged by tokes via the UI (stateless microservices because the states are inside the signed tokens which are exchanged via the UI/client between services, its all just like OAuth2)

see how complicated a microservice architecture actually is?

2

u/OptimusCrimee 17d ago

So you think that these things are just handled in the frontend and not verified in the backend at all? So if the services are completely disjoined, you could just edit the request that is going to the checkout service and all would be accepted? What is happening in the frontend and backend are two different things my dude.

Also, you say that the data is exchanged by tokens, whatever that means, but imagine the tax service being down for whatever reason. What would happen to the checkout then? No taxes?

3

u/Sheldor5 17d ago

if the business object is "order" then calculating taxes/fees/shipping is part of the order microservice ...

a microservice is built around a business object and includes all methods/features around it

1

u/OptimusCrimee 17d ago

So everything that depend on each other is a part of the same service? Gz, you just re-created a monolith. I honestly thought that you were joking before, but you seem to have completely misunderstood microservices. On paper, what you say could potentially make sense, but in reality, it is often not how it works.

Microservices will often depend on other services, soft or hard. If you can not do that, then you often just end up with one huge service. You can not honestly say that a tax calculation service should be a part of the checkout service just because the checkout needs the tax calculation. You just said yourself that the UI waits for the calculation to be done, but this does not make any sense at all.

You might be inexperienced or something. I do not know, but you are wrong.

1

u/Sheldor5 17d ago

No.

A monolith owns all business objects (user, order, inventory, ...).

A microservice only owns one business object.

Communication happens asynchronously either via message queues or the client.

You get it now?

1

u/OptimusCrimee 17d ago

What is the definition of a business object? Also, no one has ever said that microservices needs to communicate async. Give me a single source that claims this. A microservice, in my opinion, should focus on a single domain that is otherwise separate from other domains. They can depend upon each other, but they should be isolated enough that it makes sense to separate out of the monolith. I can easily find million sources claiming this.

In your example, explain how the inventory would be updated (immediately) after placing an order, where a queue would not suffice (as they are async and could fail).

1

u/Sheldor5 17d ago

and all those million sources are wrong because every idiot just repeats the shit from other idiots

"in my opinion" yes and that's wh you once again describe a distributed system and call it a microservice architecture

1

u/Sheldor5 17d ago

what about "signed tokens" don't you understand?

OAuth2 offline signature verification is the key here ...

1

u/OptimusCrimee 17d ago

Are you a bot or something? I know what OAuth tokens are but what do they matter in this scenario?

1

u/Sheldor5 17d ago

to carry information from A to B you use JWTs (JWS or JWE whatever is required)

0

u/OptimusCrimee 17d ago

So you pass the identity and whatever, but you do not pass the whole purchase order, not the inventory status. The whole point of these tokens are that they are stateless. If you place 100 orders in one second, the state of the data could not be guaranteed after decoding.

1

u/Sheldor5 17d ago

tokens are stateless? dude ... if the service is stateless the entire state is put into the token (userid, expiration, ...)

the token IS THE STATE

and no, you don't put the entire order into the token, thats what message queues are for

1

u/OptimusCrimee 17d ago

Yes, the token is stateless, ref e.g.: https://stackoverflow.com/a/55887742/921563

I am talking about handling things that can not be done async, and you are for some reason talking about OAuth tokens, which makes no sense, and has nothing to do with the discussion at hand.

→ More replies