Chat-Application | this is an android Chat Application using FireBase | Authentication library

Fixed the problem, it was because I didn't add an index for the query on firestore. I got a error from the android studio console (and firestore) that explained it see link:

https://coderedirect.com/questions/651254/firebase-firestore-query-error-9-failed-precondition-the-query-requires-an-i

You have to have a common state that is stored in a parent component, and when CustomRoom is ready, it sets the name, then RoomsDropdown is rerendered, because of the new property.

loginController

The difference is much more conventional rather than functional - the difference being side-effects vs a final consumer.

The doOnXXX series of methods are meant for user-designed side-effects as the reactive chain executes - logging being the most normal of these, but you may also have metrics, analytics, etc. that require a view into each element as it passes through. The key with all of these is that it doesn't make much sense to have any of these as a final consumer (such as the println() in your above example.)

On the contrary, the subscribe() consumers are meant to be a "final consumer", and usually called by your framework (such as Webflux) rather than by user code - so this case is a bit of an exception to that rule. In this case they're actively passing the messages in this reactive chain to another sink for further processing - so it doesn't make much sense to have this as a "side-effect" style method, as you wouldn't want the Flux to continue beyond this point.

(Addendum: As said above, the normal approach with reactor / Webflux is to let Webflux handle the subscription, which isn't what's happening here. I haven't looked in detail to see if there's a more sensible way to achieve this without a user subscription, but in my experience there usually is, and calling subscribe manually is usually a bit of a code smell as a result. You should certainly avoid it in your own code wherever you can.)

This might be related to CORS problems. I had a similar issue where i had the socketio server running on port 5000, the angular app on 4200, which the CORS policy did not like at all. I solved this using a proxy configuration and starting the dev server with --proxy-config proxy.json.

proxy.json:

You are starting the server on PORT 8000 but the client is trying to connect to PORT 8081.

Change this line,

It's the API Gateway that keeps the websocket connection alive. The browser (or whatever your client is) is connecting to the Gateway, not the lambda function.

The gateway triggers the Lambda function. You hook this up by selecting LAMBDA_PROXY from Integration Request. You can connect each route to a separate function, or have them all dealt with by one, whichever you prefer. Unless you're doing something very complicated in the function, it should only be executing for a few ms.

Communicating from the function to the original client is done through the gateway too - with APIGatewayManagementAPI.postToConnection (or you could roll your own http version using the connection URL I guess).

Would it be smarter/faster, to use one database per user

Probably not, because you will still have the same quantity of data and just have the overhead of have multiple database instances

this is not really possible to achieve this with Django?

Django is not a database manager, so the question does not really make sense. For example, Oracle or SQLite allow a single query to access multiple databases. So if you used Oracle with Django, you could have a different database per user. Anyway, even if by default Django only uses one single database connection, it can be configured to use multiple databases (thanks to @brunodesthuilliers for the info).

Database design is a rather complex operation: you have to design the tables to structure the data, the indexes, to speed up some accesses and/or enforce uniqueness, and optionaly views to easy request writing. Once this is done (and the database is used), you will have to define recurrent tasks to cleanup the database (index maintenance, archivage and purge of archived data).

If you intend to use a large farm of servers to be able to handle thousands of simultaneous accesses, a SQL database can indeed become a bottleneck, and you should considere NoSQL databases to dispatch the load on independant servers. But in this use case, Django would just be a casting error. Anyway, I know no example of real world use case where multiple databases are used just for performance reasons.