web-react | : diamond_shape_with_a_dot_inside : Another React Dev Kit | Frontend Framework library

They are on different abstraction level, so they can't really be compared as such.

Project Reactor is a general purpose reactive library. Similarly to RxJava, it is based on the reactive-streams specification. It is like Java 8 Stream and Optional, except it has support for asynchronous programming, error handling is built-in, supports backpressure and has a large number of operators (map, filter and many more).

Spring Webflux is a framework to create web services using reactive libraries. Its main goal is to ensure high scalability with low resource usage (i.e. small number of threads). Under the hood it uses Project Reactor, however, you can also use it with RxJava (or any other reactive-streams implementation) and it works well even with Kotlin Coroutines.

its very hard to give you any concrete answer here since we dont know your exact architecture.

But if you understand the problem reactive is trying to solve, and how it does it might give you a better insight into making a better decision.

The traditional servlet approach that most web servers in java uses assigns one thread to each request. So as a request comes in, one thread is assigned to it, and this thread then processes the request. If your server then does blocking calls to other servers, the assigned thread needs to wait for the response to come back.

This tends to result in that web servers have several 100s of threads that spend a lot of their time just waiting. And when i mean waiting, i mean waiting a lot. As much of 90% of the time of a thread could be spent just waiting for a blocking call. For instance the processing in a web server might take 3ms, then it does a blocking database call, and the thread needs to wait 200ms (don't quote me on the numbers).

That is a lot of resources spent just waiting.

So old way:

• one thread per request
• if 300 request then we have 300 threads
• High memory usage (each thread needs memory)
• CPU spends a lot of time waiting

Reactive solves this by having something called an event loop, and then a small thread pool that schedules work on the event loop.

I practice you can se it like this, one event loop, and then maybe 10 threads that all schedule work, the event loop just works, all the time, and the schedulers jast schedule a long line of work for the event loop to push through. So all the threads are constantly 100% busy.

In a webflux application usually the number of event loops are dependent on the number of cores in the hardware.

But this means that we need to be 100% non-blocking. Imagen we have a blocking call in this scenario, then the entire eventloop would stop, all the scheduled jobs would stop, and the entire machine would freeze until we are "un-blocked".

So reactive:

• event-loop does all the work
• small thread pool that schedules work
• blocking is VERY bad, can freeze entire application
• since less threads, smaller memory footprint
• higher CPU usage
• Possibly higher throughput

So we are basically trading memory for CPU power.

So what is a blocking call? well most calls are blocking as in you call another service and you need to wait. But this is where reactive shines, because it has one other feature.

Since it does not have one specific thread per request, any thread can make the request, but here's the thing, any thread can handle the response, it doesn't have to be the same thread.

We are what is called thread-agnostic.

Our non-blocking service can do a lot of blocking calls to other services and still stay completely non-blocking. Cause when say non-blocking i'm meaning that we are non-blocking internally inside our own application.

So what is a bad blocking call then? well its when you are calling something that is thread dependent. Meaning that you are calling something that is dependent on the same thread that made the call to handle the response, then we need to block that thread and wait for the response.

If we need to make a call, then block to wait for the response, then handle the response because we need the same thread then we can't use reactive, because then we might block the event loop and this will stop the entire application.

So for instance everything that uses ThreadLocal is bad in a reactive world, and this is where one of the major problems come in. JDBC (the database driver specification) was written inherently blocking. As it is dependent on thread local to keep track of transactions to be able to rollback. Which means that all database calls using JDBC are non usuable in a non/blocking reactive application, which means you have to use database drivers that uses the R2DBC spec.

But a rest call isn't blocking, as it is not thread dependent unless you use thread dependent functionality, like ThreadLocal which spring webclient doesn't.

So what is your quote talking about? Well spring reactor has a mechanism so that you can mix the "old way" (one thread per request) with the new way (thread agnostic). This means that if you would have a hard blocking call (calling an old database using a jdbc driver), you can explicitly tell the framework that "all calls to this database should be placed on its own thread pool" so you are sort of telling the framework that use the old way (by assigning one exclusive thread for that request) for that specific call. But remember you loose all the benefits of reactive by doing this.

So if your service is only calling a lot of hard blocking services (like old databases), you would have to constantly opt out of the reactive framework, so you would basically just build an old traditional servlet web service using a reactive framework, which is sort of an anti-pattern. So i do not recommend that.

All i have written here is general computer knowledge, how threads work, how rest calls work, how database drivers work. I can't explain how computers work in a single stack overflow post.

This and a lot more is stated in the Reactor reference and i suggest you do more research.

If you have a road with many turns and no straights, is there any purpose to buying a F1 car if you constantly have to slow down and do a lot of turns all the time?

I leave that decision to you.

According to the Firebase docs, v9 is not compatible with FirebaseUI,

...

is there any way to make FirebaseUI work after upgrading Firebase to v9?

If you want to be adventurous and try to get these things working together, you can start with npm i --save firebaseui@next. At the time of this writing, that will install firebaseui@0.600.0 which is presumably a pre-release for firebaseui@6 which is intended to add compatibility with firebase@9.

If you want to be really adventurous, you can try applying the change set at https://github.com/firebase/firebaseui-web/pull/850, but that appears to be undergoing active development (comments as of 3 days ago). Perhaps it will be merged and released in the not-too-distant future and hopefully your issue will be resolved by it.

After some research I found that, this can be solved with the Flux itself. It is enough that we add startWith method to the Flux. As in the definition of the startWith method.

Prepend the given values before this Flux sequence.

So we prepend our Hello message to the start of the Flux and it will be published first.

I refreshed my npm and started again and it worked. Not sure what was the issue. But the same code works now.

Your problem is probably here:

Consider using .awaitBody() instead of .block() (which is blocking operation)

Something like:

After some investigation i found that when you register a component, it is case sensitive, so if you look in my index.jsfile i have this line of code:

Set content type for webclient.