Worker Services configure Serilog

A worker service is a type of Background Service that are generally use for long-running task. They can be seen as the equivalent of Windows Services in the .NET Framework, though a worker service is not limited to just windows. If you are building a worker service, then more than likely you will need to be able to write log data, be that general information of the worker services or perhaps just errors....

August 12, 2021 · Yunier

JSON:API - Creating new resources

So far in my JSON:API series I’ve covered the home resource, adding your own resource, adding an exception handling middleware and how to expose relationship between resources. For the today’s post, I would like to cover creating resources. I will update the chinook project by allowing POST request on the customers collections to add new customers. To get started, the customer controller needs to have a method that will accept the incoming POST request....

August 8, 2021 · Yunier

Running lighthouse on CI/CD pipeline

In the world of front end development there is no better tool than Lighthouse. Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO and more. The only problem with lighthouse, at least from my experience, is that it is not used until after the app has been deployed....

June 5, 2021 · Yunier

GraphQL is protocol agnostic

I’m seeing many API developers, specially those that come from a REST background, struggle with GraphQL simply because they are introducing protocol concepts into their GraphQL documents. give it a REST... pic.twitter.com/sUxqL4ACdj — I Am Devloper (@iamdevloper) November 13, 2020 GraphQL is not bound to any network protocol, it is most often implemented on top of the HTTP protocol and it only uses the most basic features of HTTP. That is because GraphQL treats HTTP as a dum pipe....

June 4, 2021 · Yunier

Problem Details for HTTP APIs

One of the many benefits of working with JSON:API and GraphQL is having a standardize way to communicate failures to a client. If you are not working with a spec like JSON:API or GraphQL, then you are in the hands of the developer that built the API and every developers implements error handling differently. Almost every HTTP API that I've consumed implements errors differently. Can we just agree to use Problem Details and be done with it?...

May 11, 2021 · Yunier