SMFloris

It is so much fun!

IMO, kubernetes is overkill for a small non-homogeneous home cluster.

What I use and really recommend is using systemd +/- docker. It just becomes so darn simple. Do not go the compose route (that route is filled with sadness of the incomplete stacks because db container failed silently kind) - instead aim to decompose the compose files and write a separate systemd service file for each of them, you can then assign limits separately.

I don't want to set anyone on the path ... but I use NixOs and this is so easy to do there.

So 400 writes per second is not exactly what I would think about when thinking about a "Production" environment.

Shout out to the great people in the KDE Community.

I was in high-school and being enamored with the open-source concept ("You mean I can modify anything I want about it?" - hah) I wanted to make my mark in a simple little way. I remember fondly when lurking around in IRC and somehow decided I would change the login screen. Got pointed to the KDE greeter channel and that is how it all started for me. I kept annoying them, did not know how to build, compile, nothing. Thanks to d_ed for answering my annoying questions, that is how it all started for me.

Seems so much work for something already implemented with messaging brokers, though.

In my opinion, clients themselves shouldn't worry about if the server is ready or not, only handle if the server does not respond in x seconds and then simply crash or error out. It is the same you would to with any other external service call.

I think the biggest change to gRPC is to the way I thought. Dumb clients was always something that I chose because it was an order of magnitude simpler to reason about. gRPC comes in and changes this by making the clients smart and the servers smarter, which brings allot of complexity to the table.

Also, indeed the configurations are so obscure.

Thank you very much for these articles. Really top-notch work and provided me with some great insights!

Never tried with MsgPack, but I did try Protobuf. The reason I dislike Protobuf is that there is an extra code generation step I need to do. When using a compiled language, I guess you don't really mind the extra code generation step since you also get some safety from the compiler so you don't wind up miss-using the generated code. It is not the same when you are using an interpreted language that doesn't have really good strong typing. You will have to run a static code analyser and be very careful every time you do a change to the interface.

Since in my experiments I was calling a method in Php through RabbitMq from a Rust worker, so it just proved allot simpler to just use json. Also, I measured the time it took to:

1. Make a request to the Php API

2. Php sends the rpc message on the queue

3. Rust processes that message

4. Php catches the response from the worker

5. Php returns the response to the http client

It was <10ms running the cluster locally regardless if I used Protobuf or simply json.

Recently I started delving into gRPC vs RPC over RabbitMq using json as the mesage format. I saw that for small to medium sized messages, gRPC is actually slower. Of course, this was just a small scale experiment so I don't think nothing of it.

Does anyone have a sort of infrastructure/architecture guide at a bigger scale for gRPC?

My biggest questions range from: How do you actually load balance the servers? What happens if you have a sudden influx of requests but don't want to auto-scale? Do you still need a sort of queue-ing system in front of the gRPC server?

In my research I wasn't able to find some noteworthy articles about this and thus triggered my curiosity.

Where Conan doesn't really shine is crossplatform dependencies. For example, when a dependency requires to have been built with a specific toolchain. Thus, if your goal is write once and run everywhere you'll still have to build dependencies yourself.

Loved it! It gets crazy with the pawns, I was so surprised. The visuals of the game are so and so, but they are really cool nonetheless. Two thumbs up from me!

I didn't see it back when I was doing Qt, but writing a Qt app for every platform is hard. In theory you can have Qt apps on Android, iOs, Linux, etfc but in all fairness, it is just too much of a hassle. Big headache with toolchains, dependencies, it is just not worth it nowadays.

"Write once, run everywhere" was a nice motto for Qt and I even bought it for a while but yet again does not work in practice. Flutter, on the other hand, actually works. Sure it doesn't have all the bells and whistles of OS integrations, but it is getting there. I hate the language itself, but I can't deny that it works beautifully.

If you think about it, the Qt way of doing things was quite novel back in the days and had allot of promise, but I feel that the main thing that held it back was C++ (still no official package manager and no cool CLI tools in 2021!!). I am sad that I left Qt behind since it was an amazingly modern platform when I used it, but I am glad I don't do C++ anymore.

A while back we explored the use of Cassandra. We wanted to keep some event related data there and for it to be relatively fast read-wise in order for us to do all sorts of reporting based on it. So we wrote allot and wanted to read fast. Seemed like a perfect store for our timestamped events, especially since we wanted to not even use deletes and has in-build record deduplication via its primary key. Turns out, it is not that perfect.

Other than what the article described, I can also add:

1. It has a steep learning curve, but you do get to see the advantages while you learn it. But then, everything comes crumbling down.

2. The setup is a pain locally. Then it is a pain to set it up in prod and manage it. The tooling itself feels very unfinished and basic.

3. No querying outside primary index on AWS Keyspace if you want it managed. Also, any managed variants are EXPENSIVE. I mean, every database is fast if you only query by the primary index so why pay extra?

It is just not worth it. For example, we winded up using MongoDb and it turned out to be fast, scalable, had mature tooling and we can keep tons of event related metadata in it and it is easy to manage and doesn't cost a fortune.

Hah! Brings back old memories. I actually did something similar for an RPG I was trying to create from scratch using Qt3D (back in the day when it first came out and was getting stable, QT 5.8 maybe).

Had the whole isometric world down and used qml to script monsters and abilities.

Great and fun experience, thanks for sharing!