We often use GitHub to create a compare view, and list pull requests (PRs) for releases. However, GitHub limits the number of commits you...Documentation GitHub Git
Using our Hugo-based documentation site, we typically publish release notes once per week. My usual process includes the following: M...Documentation Hugo Archetypes
This is an updated post of the original here. Whether you’re new to the frontend at RIMdev or looking for more about our Frontend team...Team RIMdev Frontend
If you’ve ever worked in Azure Data Studio, you may find tab colors very useful. They allow you to visually separate different connectio...Documentation Azure Data Studio
If you’re not familiar with Platform UI, it’s a utility rich CSS framework we created. As we look to migrate all of our apps and static ...UI UX CSS Sass
Get ready to celebrate because, as of Friday, September 18, 2020, Evan You, creator of Vue.js, announced Vue 3 is officially released. He...vue3 frontend development
Typically with ASP.NET Core 3.1 when no specific authorization requirements are set all endpoints are publicly accessible. When you’re wo...asp.net core
We’ve been using Swagger via Swashbuckle for some time with our ASP.NET Full Framework applications. As we’re moving toward ASP.NET Core ...asp.net core
We’ve spotted some strange behavior before with ASP.NET Core and JSON serialization/deserialization, and I eventually made it back to try...asp.net core
As we create CSS components in our internal framework, we typically try to use little if no JS. Our tooltips should be no different. We...UI/UX frontend CSS Responsive Design
Imagine you’re using Elasticsearch with your strongly typed C# models and nameof(MyProperty) and wondering why it doesn’t work. Turns out....NET
I have been working as a software developer for almost three years, the most common exception or bug I made is NullReferenceException -Sy....NET C#
Testing is an important step we can take as developers to reduce bugs in our code, but testing seems to be one of the best practices that...Vue.js Jest Testing
Last week I attended the annual user experience conference Convey UX in Seattle, where 50 UX leaders from all over the world shared their...UI/UX frontend conference conveyux2020 conveyux
We run a number of web applications at Ritter Insurance Marketing. Our primary datastore for these applications is MSSQL / SQL Azure. Our...SQL
We’ve been working through upgrading our core applications from ASP.NET full framework to ASP.NET Core. Over the years we’ve assembled an....NET
Do you want to save 80% of your bandwidth to your search provider? Do you want to deliver content to your users faster? With this one trick you can!
As shown in the graphic above, using this trick we reduced the amount of bandwidth we consumed by 80%!
I’ve found backend services communicating without compression a few times in my career. Lack of compression is an issue because it is mostly invisible. When you interact with a RESTful API through a browser, you can see whether compression is occurring in the developer tools. Those calls that your back-end services are making are opaque unless you are intercepting the traffic with Fiddler.
At a previous employer, I was informed of a compression issue because the shared on-call phone was going off at around 2 AM in the morning. After some investigation, we learned that our search provider would sometimes return large result sets. When this happened to a few customers during a period of low traffic, the issue would set off ALL THE ALERTS. The alerts were not good for my mental health because low traffic times happened in the middle of the night. We ended up adding compression, we saved a fortune on bandwidth, and our customers were better off as well.
The most recent example is when I found a compression issue here at RIMdev. We love using Elasticsearch because it enables high-value scenarios that our users appreciate. One day I was attempting to optimize some queries while I had Fiddler open. I noticed that the results from Elasticsearch were not compressed. In some instances, we were getting results that were 400kb and could take more than a second to transfer! By enabling compression, we shaved more than a second off of response times while reducing the data transferred between the app and data center by ~80%.
To solve this issue at RIMdev, we used this code to enable compression for the Elasticsearch C# client, NEST.
var settings = new ConnectionSettings(connectionPool) .EnableHttpCompression() // this line enables http compression! // a lot of other settings ; return settings;
I told you it was ONE SIMPLE TRICK! You may have to configure your Elasticsearch cluster to compress results, but it just worked for us. We are ready to help you in the comments if you any questions or concerns.
Debug your services occasionally with Fiddler. Open and watch the network traffic your applications produce. You might find low hanging optimizations with high impact results!