Day: August 31, 2018

Logging information in .NET, or really in any production application, is invaluable. In many cases, developers don’t have direct access to the production environment to debug issues. Good quality logs are the difference between solving problems like Sherlock Holmes and stumbling upon solutions like Inspector Jacques Clouseau. As you can imagine, we’re pretty big on logging here at Stackify, and we’ve written quite a few other blog posts on .NET logging frameworks. I’d encourage you to try out the search and read a few of our previous articles.

Top .NET Logging Frameworks Comparison

In this article, we’ll take a look at three of the most popular logging frameworks in the .NET space: log4net, NLog, and Serilog. If you’ve read any of my comparison articles in the past, you’ll know that I typically end up with some wishy-washy conclusion like, “It all depends on your situation” or some variation of “different spices for different mices.” But not this time! This time, I promise to declare one winner; one logging framework to rule them all and in the CLR bind them. https://goo.gl/cmSuKD #DataIntegration #ML

#ICYMI: I was working on a serverless app for Streamdata.io that takes posts to Hacker News and streams them into an Amazon S3 data lake, and I came across the Algolia powered Hacker News search API. After being somewhat frustrated with the simplicity of the official Hacker News API, I was pleased to find the search kindly provided by Algolia.

There is no search API available for the core Hacker News API, and the design leaves a lot to be desired, so the simplicity of Algolia’s API solution was refreshing. There is a lot of data flowing into Hacker News on a regular day, so providing a search API is pretty critical. Additionally, Algolia’s ability to deliver such a simple, usable, yet powerful API on top of a relevant data source like Hacker News demonstrates the utility of what Algolia offers as a search solution — something I wanted to take a moment to point out here in this article. https://goo.gl/eQFcJb #DataIntegration #ML

#ICYDK: I’m doing a lot of thinking regarding how JSON PATCH can be applied because of my work with Streamdata.io. When you proxy an existing JSON API with Streamdata.io, after the initial response, every update sent over the wire is articulated as a JSON PATCH update, showing only what has changed. It is an efficient and useful way to show what has changed with any JSON API response while being very efficient about what you transmit with each API response, reducing polling, and taking advantage of HTTP caching.

As I’m writing an OpenAPI diff solution, helping understand the differences between OpenAPI definitions I’m importing and allowing me to understand what has changed over time, I can’t help but think that JSON PATCH would be a great way to articulate change of the surface area of an API over time — that is, if everyone loyally used OpenAPI as their API contract. Providing an OpenAPI diff using JSON PATCH would be a great way to articulate an API roadmap, and tooling could be developed around it to help API providers publish their roadmap to their portal and push out communications with API consumers. Helping everyone understand exactly what is changing in a way that could be integrated into existing services, tooling, and systems — making change management a more real-time, “pipelinable” (making this word up) affair. https://goo.gl/pw83fm #DataIntegration #ML