Building Async and Cloud Native organizations - Issue #13

Welcome to my weekly newsletter! Every week, I bring you the latest news, updates, and resources from the world of coding and architecture. I'm so glad you've decided to join me, and I can't wait to share my insights and expertise with you.

I hope you'll find this newsletter to be a valuable resource, and I welcome your feedback and suggestions. If there's something you'd like to see more of, or if you have any questions or comments, please don't hesitate to reach out to me.

Thank you for joining me, and happy reading!

REST and APIs

Failures are a given, even more with network traffic. This means that requests that fail to be processed can most likely be offered again. Applying this retry strategy solves most of the time these transient or random faults.

This does imply that requests do not have side effects; even when we send multiple times the same request, the outcome should be the same. This is called an idempotent operation.

There are numerous ways to implement an API that support idempotent operations, and the team at Amazon share their implementation:

Not the first time, and certainly not the last time as well; data that has been leaked from an API breach from Twitter is being used for further attacks using social engineering campaigns. When you have the handles, follower count, creation data, and email addresses, you can use this information for more targeted attacks.

Coding technicalities

You might have used Swagger or NSwag, which can be used to extract OpenAPI specifications from your code. There is another specification for async APIs, namely the AsyncAPI.

The developers from LEGO created a library allowing you to describe the async API and export it to JSON or YAML.

Running code in the background is nowadays a simple task; add an IHostedService implementation, register it at startup, and runs your code. But what if you need some kind of scheduling, logging, and orchestration? Quartz.net, Hangfire.io are some nice solutions, but the below implementation by Niels Pilgaard can also be a good fit.

GitHub related

Maybe unavoidable when you look at the changes happening at the mother company Microsoft, but GitHub also announced some staff cuts and changes. It is laying off 10% of the workforce and is transitioning to a fully remote workplace.

Merge queues

When you are in a large team and creating features in separate branches, you can run into the issue that pull requests get into each other way. Every time a pull request is merged, all the other branches need to be updated as well. Meaning another round of CI checks, and when another PR is merged, you will need to start again.

With a merge queue, this process is automated by ensuring that each pull request queued for merging is built with the pull requests ahead of it in the queue.

The merge queue creates temporary branches with a special prefix to validate pull request changes. The changes in the pull request are then grouped into a merge_group with the latest version of the base branch as well as changes ahead of it in the queue. GitHub will merge all these changes into the base branch once the checks required by the branch protections pass.

This feature is currently in beta and only available for GH Enterprise Cloud as well as open source repositories.

Blocks

Recently I got access to GitHub Blocks, an experimental interface that lets you extend the interface of your repositories with custom components. You can create those blocks yourself or publish to and use with others.

A block is a piece of React code, a component, with some predefined inputs and outputs. It can update the UI and call the GitHub API. They can operate on files or on folders and are created in TypeScript.

Push the block to a repository, tag it with github-blocks and GitHub will handle the hosting, building, etc for you.

So what can you do with it? Well, almost any kind of activity you can think of! You can navigate to any repository by using the URL structure blocks.githubnext.com/{owner}/{repo}

You can select which type of block you want to use, so when I go to my blog repository hosted on GitHub, I can select an image viewer instead.

Another kind of block is a minimap, showing me the type of files I have:

Blocks can also collect data from the GitHub API, so when I look at an open-source repository like Serilog.Sinks.Elasticsearch, I can select the Community block, which will render a completely different overview.

For files, you can get other visualizations, like a CSV table, a code editor, or a simple JSON viewer. Just select what suit your needs.

Like for a CSV list, you can show the results in a speadsheet view. Sorting, filtering and visualization of the data is easy. Want a more graphical overview? Then select the charts block instead.

As you can see, the possibilities are endless. When developing a block, you indicate what kind of functionality it adds:

{
  "type": "file",
  "id": "css-block",
  "title": "Styleguide block",
  "description": "View selectors in a css file",
  "sandbox": false,
  "entry": "blocks/file-blocks/css.tsx",
  "matches": ["*.css"],
  "example_path": "https://github.com/githubnext/blocks-tutorial/blob/main/global.css"
}

The above snippet shows a block that is intended for files and in particular for css stylesheets. This helps in reducing the amount of blocks that you can select.

If you want to know more or signup for the beta, visit the GitHub blocks website.

Computing in general

ChatGTP was already pretty good at creating applications. Ask it to create a piece of code, and you get a decently good piece of code. However, when you try to run it, you will notice that some constructs are outdated or did simply not compile.

The OpenAI organisation is now investing in improving its models so that basic coding becomes easier.

As the engine is also powering GitHub Copilot, we will see better results, hopefully soon. Exciting times ahead, or as the head of AI of Tesla is putting it:

Which boiles down to write down in the best natural language which the AI could interpret to create what you want and need.

Visual Studio Code has so many tricks that this site is a great resource for seeing all the possibilities. Like soft undo’s, or Azure Functions support…

Do you have a backlog? How many items are on it? And is it shrinking at all? Most likely, it is an ever-growing list of work to be done, while you actually pretty well know what needs to be done.

You can’t really plan for more than 2 a 3 sprints in advance, so having a list of items is more waste than benefit. Lucas Costa makes a case for keeping the backlog as short as possible if you ever need one to start with:

Helpers and utilities

Good old paint; some people can make whole masterpieces with it. The good thing is that there is an online version as well. So take out you pencils and start drawing!

Computer laws

Correct me if you think I m wrong…

I hope you've enjoyed this week's issue of my newsletter. If you found it helpful, I invite you to share it with your friends and colleagues. And if you're not already a subscriber, be sure to sign up to receive future issues.

Next week, I'll be back with more articles, tutorials, and resources to help you stay up-to-date on the latest developments in coding and architecture. In the meantime, keep learning and growing, and happy coding!

Best regards, Michiel