RabbitMQ Data Layer update
Holidays are over and I'm back to work and spending a little less time on my side projects. But, I took some time today to dig back in a bit. Mostly, I was trying to get my React pages to work. Still a noob there. And it was bothering me that I couldn't even get a simple grid to render.
Finally did sort it out. Seems like a combination of being mistaken about the format of the data coming back, and out of date JS files still being served up. Other than that, it was already more or less working.
Anyway, what struck me was the speed.
I had done a quick UI using Razor pages at first. But, then decided to check out some other UI frameworks before getting too deep into any one or another. Since I can't develop WPF apps in Linux, I decided to check out some of the other Web based UI frameworks which .Net Core has support for. Not really a bummer, as I was kind of hoping for a web based approach anyway. But, laziness struck at the end of my holidays :)
But, why I'm looking at React in the first place isn't what is interesting to me right now.
When I wrote the first version in Razor, in addition to just not liking it, I noticed the pages were loading slowly. I assumed this was caused by my choice of data layer. It was disappointing, but I knew I was really being more experimental than anything.
It turns out it may have been rendering or communications related though. Because in React, the performance is near instant. There is no perceptible lag at all. And the controllers are relying on the exact same base class to transmit the request and receive back the data.
The only differences would be framework related. Specifically, if there are any communication differences between the UI and controllers, and rendering.
Again, not really what interests me right now.
What IS interesting is seeing what I hoped to see. The performance is great. I mean, I would still be completely unsurprised to find it is slower than other more traditional methods. RabbitMQ is really not optimized for this sort of work.
But, I've basically evolved from being a disheartened that the speed might be bad enough to be perceptible, even if it wasn't that horrendous, to now where I'm thrilled.
This doesn't change my earlier stances. I don't think I would recommend it for dealing with high volume payloads. Though, with some work to ensure reliability of the messaging, I think could handle high volume of traffic and massively distributed systems.
The great thing here is the flexibility you get when using a mature MQ solution. The types of exchanges and the ability to scale the publishers and subscribers are nearly endless.
In short, I'm calling this a success already.
Finally did sort it out. Seems like a combination of being mistaken about the format of the data coming back, and out of date JS files still being served up. Other than that, it was already more or less working.
Anyway, what struck me was the speed.
I had done a quick UI using Razor pages at first. But, then decided to check out some other UI frameworks before getting too deep into any one or another. Since I can't develop WPF apps in Linux, I decided to check out some of the other Web based UI frameworks which .Net Core has support for. Not really a bummer, as I was kind of hoping for a web based approach anyway. But, laziness struck at the end of my holidays :)
But, why I'm looking at React in the first place isn't what is interesting to me right now.
When I wrote the first version in Razor, in addition to just not liking it, I noticed the pages were loading slowly. I assumed this was caused by my choice of data layer. It was disappointing, but I knew I was really being more experimental than anything.
It turns out it may have been rendering or communications related though. Because in React, the performance is near instant. There is no perceptible lag at all. And the controllers are relying on the exact same base class to transmit the request and receive back the data.
The only differences would be framework related. Specifically, if there are any communication differences between the UI and controllers, and rendering.
Again, not really what interests me right now.
What IS interesting is seeing what I hoped to see. The performance is great. I mean, I would still be completely unsurprised to find it is slower than other more traditional methods. RabbitMQ is really not optimized for this sort of work.
But, I've basically evolved from being a disheartened that the speed might be bad enough to be perceptible, even if it wasn't that horrendous, to now where I'm thrilled.
This doesn't change my earlier stances. I don't think I would recommend it for dealing with high volume payloads. Though, with some work to ensure reliability of the messaging, I think could handle high volume of traffic and massively distributed systems.
The great thing here is the flexibility you get when using a mature MQ solution. The types of exchanges and the ability to scale the publishers and subscribers are nearly endless.
In short, I'm calling this a success already.
Comments
Post a Comment