Posts

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. I’ve decided to call the method CreateCustomerResource, the method will accept a JSON:API document from the request body. The full method signature is defined below. ...

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. I haven’t been involved in any project that utilizes lighthouse upfront, certainly not on the ci/cd pipelines. Which can be done using lighthouse-ci. There is also another way to get lighthouse running on your ci/cd pipeline, it involves executing lighthouse while you are running your unit test regardless of the unit test engine, be that Jest or Mocha. However, these tools lack the ability to invoke a web browser, after all, lighthouse can only be run against an actual website. ...

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. Introducing protocol concept such as a 404 Not Found status code into your GraphQL documents will only cause you development pain. ...

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? ...

I don’t believe I’ve mention this before here, but I am a huge fan of Hey. By far the best email service I have ever used. What makes Hey even cooler is the team behind Hey sharing they engineering approach to different problems. Be that through various tweets or blog post like Scaling the hottest app in tech on AWS and Kubernetes which outline how they use k8s. Recently, they shared how to tackle ay11 under hey accessibility is a lot of work. One thing that stood out was to me was their usage of axe-core. Axe-core is an accessibility engine for automated Web UI testing. Which reminded me of playwright, so I started to wonder if the two could be combined, turns out they can be. Let’s explore how to do that. ...

A few weeks ago I was looking for an end-to-end testing framework. An alternative to Selenium, and all the other end-to-end frameworks. I came across a project called Playwright. Playwright is a new end-to-end framewrok created and maintained by Microsoft, it allows you to test web applications on different browsers. Some the major feature it provides are as follows. Playwright has full API coverage for all modern browsers, including Google Chrome and Microsoft Edge (with Chromium), Apple Safari (with WebKit) and Mozilla Firefox. Supports multiple languages like Node.js, Python, c# and Java. First-party Docker image and GitHub Actions to deploy tests to your preferred CI/CD provider. Use device emulation to test your responsive web apps in mobile web browsers. Provides APIs to monitor and modify network traffic, both HTTP and HTTPS. Any requests that page does, including XHRs and fetch requests, can be tracked, modified and handled. While those feature are all great and useful, they don’t measure up to what I consider to be the best feature of Playwright. That is being able to create and execute test as easily as unit tests. You can also leverage tools like qa wolf and headless-recorder, these tools record any action you take on the browser, those actions are then converted into Playwright scripts. ...

I am currently building a JSON:API driven API on .NET 5, the project is called Chinook after the Sqlite Chinook project. The API is mature enough for me to introduce filtering via the Filter query parameter used in JSON:API. I would like to support dynamic filtering, I want to avoid creating nested if-else/switch statements that check if a given input is part of the filter criteria, and if it is then it gets appended to a filtering clause. For example, take the following API request, it uses the OData filter syntax. ...

When I first started to learn about GraphQL I was somewhat surprise to learn that the GraphQL specification did not provide any guidance or spoke of any methods to handle asynchronous request. By asynchronous request, I mean request that cannot be completed within your normal request-response context. For example, take an API that aggregates orders by combining various types of filters, the API may allow you to filter by only orders that are greater than $100.00, or orders placed in certain date range, or orders that have a particular product and so on. Depending on the amount of data and filters used, the query to get the data may take a couple of minutes, maybe even hours. The question now becomes how to best handle long-running request in GraphQL. ...

My Chinook JSON:API project is now in a good enough state that I feel comfortable hosting it on a live server. Here is the base url, https://chinook-jsonapi.herokuapp.com/, I highly recommend using some kind of JSON viewer if you want to interact with the API. If you are on a Chromium base browser then I recommend using JSON Viewer. Remember, the API does not support filtering, pagination, sorting or include resolvers and it only supports READ operations. I’m hoping to add filtering soon but I first want to dedicate a blog post or two on building dynamic LINQ queries using expression trees. That should be fun! ...

.NET Core 2.2 introduce a small feature known as Query Tags. It allows you to annotate queries generated by EF Core. This is super useful for debugging purposes, after all one of the main complains you often hear about EntityFramework is the over completed SQL statements it generates. I am currently working on a project called Chinook, it demonstrates how to build a JSON:API on .NET Core. The project uses EF Core to query a SQLite database. Here is an example of one of the LINQ queries used to get a collection of users. ...