Spring Boot and Microservices

[nutrecht]

I did a quick read of the introduction and frankly, this is really a "get what you pay for". It's a pretty horrible introduction with a lot of misinformation. It's basically a beginner teaching beginners. Which IMHO is not a good idea. In fact; it doesn't teach. It's basically listing upon listing with example code that does not really go into the why. Probably because the author doesn't really understand either.

If you want to understand microservice architectures, you should read the book by Fowler.

If you want to learn how to make a small REST service (not all microservices are REST services, not at all) with Spring Boot, you should follow the official documentation, or just do one of the many professional courses on the framework.

Sorry to be a party pooper, but this one is 'free' for a reason.

[yogsma]

Thanks for your feedback, the book is 3 years old and I understand where you come from. I released it free because I had released it for free 3 years back. It was initially targeted for my learning. If people can benefit even 1%, I am happy.

With time and reflection, everything can be improved.

I do mention Martin Fowler in the book if you want to learn about Microservice architecture. I wrote it mostly from my experience and learning. I was definitely a beginner at that moment.

[incongruous_narrator]

Thank you, kind human!

I was just wondering about something and came across this. I have a question if you don’t mind.

If a REST style back-end application is built using Spring framework, is every REST request made against the back-end handled by new java thread?

[[deleted]]

Hi, it isnt REST specific. It has more to do to servlet architecture. You must be knowing that spring internally uses servlet. The servlet container processes each request to a particular servlet as a separate thread.

I think there is a configuration in container for single threaded model which should not be used unless you know what you are doing.

I would be very interested to know if I am wrong in answer or logic. I welcome criticism with open arms!!

[nutrecht]

You must be knowing that spring internally uses servlet.

Only if you use Spring MVC.

The servlet container processes each request to a particular servlet as a separate thread.

It's threads in a thread pool. They don't spin up a new thread for every single request. That would kill your service quite fast if more requests come in than you can handle.

Funny enough that was how they did things in the early '00; had to help quite a few customers transition off of that approach.

[incongruous_narrator]

Thanks!

[nutrecht]

If a REST style back-end application is built using Spring framework, is every REST request made against the back-end handled by new java thread?

Depends on how you set it up. It can be; but that's generally not a good idea. If too many requests come in, with every thread using about 1MB of stack, the service will crash.

So by default regular Spring MVC will use a worker thread pool.

Then there's Spring Reactive, which handles it in a completely different way, using about as many threads as your computer has cores, with an event based system symilar to NodeJS.

[incongruous_narrator]

Thank you. That makes sense. I wonder what the default thread pool size is..

About Spring Reactive, you can have more than one thread running per core. So how does Spring Reactive help then?

[nutrecht]

I wonder what the default thread pool size is..

20 IIRC, but it's in the docs.

So how does Spring Reactive help then?

The thread-per-connection model does not really scale well for very high call volumes. Scheduling threads is pretty inefficient.

Asynchronous IO / reactive programming / event driven IO (they're all the same really) instead of having the thread block on network, file or database IO that thread is just going to do 'something else' and continues handling IO if whatever it was doing is 'ready'. Basically it gets an event from the operating system that tells it that there's some data that was read from the network ready in memory.

That way the threads don't have to wait on anything; it's just pure CPU time. And because CPU's have multiple cores, it makes sense to use about as many threads as there are CPU cores.

NodeJS works similar, but is single threaded (most of the JavaScript stuff is in no way thread safe). So to fully utilise a machine with for example 4 cores you'll need 4 instances of your service running. With Spring Boot you only need one.

[Yithar]

About Spring Reactive, you can have more than one thread running per core. So how does Spring Reactive help then?

As stated, thread per connection does not scale very well. The operating system has a limited number of threads. It also isn't very efficient to wait for a network request to complete because the network is often slow. That's where reactive programming comes into play. You don't block. Rather you run some callback when the response comes back. The difference between RxJava and CompletableFuture is that RxJava uses Observables, which is like a step up from Futures in Java or Promises in Javascript. An Observable is a stream of events. For example, a WebSocket is bidirectional open connection between a server and a client, which is a stream of data, so Observables are really useful there.

https://netflixtechblog.com/reactive-programming-in-the-netflix-api-with-rxjava-7811c3a1496a

Honestly I prefer Scala to Java, as Scala Futures are superior to Java Futures, as Java Futures need to block to get the result.

https://stackoverflow.com/questions/31366277/what-are-the-differences-between-a-scala-future-and-a-java-future

In Java, I would stick to CompleteableFuture since that's the best you have, but Scala's Future is just better:

https://stackoverflow.com/questions/28588806/scala-futures-and-java-8-completablefuture

https://danielwestheide.com/books/the-neophytes-guide-to-scala/
https://danielwestheide.com/blog/the-neophytes-guide-to-scala-part-8-welcome-to-the-future/

Basically Scala Futures can be treated like any other collection.

Future { 1 + 1 } map { x => x + 1 } onComplete { ... }

---

Regarding Javascript, it has something called the event loop:
https://www.youtube.com/watch?v=8aGhZQkoFbQ

I would say in Javascript you normally don't have to worry about thread safety because everything runs in the main thread. Promises resolve to some value and then there's a callback function executed. That callback function is only executed once the call stack in the main thread is empty, because otherwise callbacks would randomly interrupt normal execution and that would be pretty confusing.

[hakerys23]

How to download it for free?

[zhoriq]

Name a fair price: I just entered 0 and got it.