Kenny van Meines @ Techorama 2022
Together with Niels, Stephan and Cristo, I went to Techorama Belgium. It’s a two days nerd event with tons of international speakers. This event is mainly centered around .NET, C#, and Azure. The event’s theme was “Las Vegas”, so you could find a lot of gambling stages to win various prizes. The event was held at Kinepolis Antwerp, so we could follow along in the fantastic cinema seats of Kinepolis. And last but not least, there was food and drinks the entire time of the event.
Building modern applications with GraphQL 2021 and beyond in ASP.NET Core 6 - Michael Staib
GraphQL fixes the problem where the client often gets too much data at once or needs to do multiple API calls for a specific piece of data. One API call can get all data required for one page. The API call contains an empty JSON tree with all the needed properties. After completion, all the fields are filled in just like a typical API call. This solution also works for streaming data.
Personally, I think GraphQL can be helpful if you have to deal with many API calls. In my current project, loading a random webpage for the first time would trigger between 100 and 300 API calls taking 9 seconds. Navigating from one page to another would start between 10 and 40 API calls because caching takes 3 seconds. Certain API calls are less important, and we try to make all the data load and show async. But knowing that in an HTTP1 setup, chrome can only handle 6 API calls simultaneously, with some bad luck, the whole page might appear to hang for a while. If we could bundle API calls, we could end up with a scenario where the longest wait time for one API call becomes the longest wait time overall.
Ofcourse, in my current project we could already solve part of the problem stated above by making the server use HTTP2 instead of HTTP1. Where HTTP1 can ( in chrome ) only establish 6 connections and therefore only do 6 API calls, HTTP2 has only one connection but can perform an unlimited number of API calls in theory. It’s up to the server to decide how many calls are allowed simultaneously. While this sounds like the ultimate solution, it’s obviously not recommended to keep the default set to an unlimited amount. Else the server might become the victim of attacks such as DDoS. So even with HTTP2, GraphQL stays effective by lowering the load on the server and therefore creating a better performance between client and server.
As for a full-stack web developer, I would not recommend GraphQL above REST. GraphQL has a lot of benefits if it comes to performance for the end-user. It also makes the life of a frontend web developer easier. But the person responsible for the API will have to create a schema and add resolver functions to retrieve and combine the data. In addition, caching is more complex than REST. And overall, it will require much more work on the server-side.
An excellent example of this technology is the Facebook mobile app. At first, Facebook used REST to get their data into the client app. But the users started to complain very quickly because it was slow and the battery would become hot very fast. GraphQL speeds up their data fetching and also fixes their battery draining problem.
Mixing Paradigms with the Latest C# Language Specification - Zoran Horvat
Zoran showed us how to use functional programming in an object-oriented language like C#. In fact, most c# developers are already using functional programming by applying LINQ. With LINQ, we can chain functions like: Where, Select, Take, … . Inside these functions, we can reference another function or write some small logic. But the fact is that the LINQ functions are an abstraction of what we want. For example, with the Where function, we don’t have to write the part where we loop over all list items. This way, we make the code more readable, shorter, and for the same input, we get the same output. This last part is also a fundamental rule and is often referenced as “pure functions”.
He used a blueprint of a Tic Tac Toe game to show us various techniques. At first, he created some functions with very specific names and bound some of them to the HTML. Because even a small and simple game can be hard to start writing code with, he filled them in with some almost hardcoded data. He used tuples and records instead of objects to get started quickly. In the newer versions of c#, tuples can have named values making it easier to know what it returns. He explained how tuples are not really used for production code. However, tuples are an excellent way to start prototyping a feature, and they are instrumental in unit tests.
As he kept going, tuples became records or normal objects. Records are relatively new and easy to create. Record types use value-based equality, making it easier to compare them (there are limits, though). He also started to use LINQ and self-made functions to wire up everything. It looked very concise and clear what he was doing.
I like functional programming a lot. You don’t have to handle the global state of your objects. Instead, you are forced to work with immutable data. And for the same input, we get the same output.
