Dollar $ign is back in JS, don’t worry it’s not JQuery

It’s made its way back in Svelte. It is used to make statements reactive.

Reactivity is not new to software engineering, anybody with basics of Excel knows it.

For example this simple function below makes B3 react to changes in B1 or B2

Here is a Svelte implementation of the same thing, notice line 5 and the usage of $: that makes sumOfTwo react to changes in val1 or val2. Internally Svelte is using JavaScript’s label syntax

If you want to edit and try the REPL here

This also works across different components using Svelte stores, but how stores work is worth going through in another post. Now, go fix some bugs!

Lost in Translation

What I lost actually is some code, while translating an app from React to Svelte. Reducing the code size significantly, at the same time it made it simpler to read and reason about the code.

This is not going to be a comprehensive guide, explaining whether Svelte is better or React, there are many of them on the web already.

Two key aspects in which Svelte is different than React (or any other popular library)

Its a compiler, which turns your Svelte code into JavaScript/Html/CSS. So, unlike React, Svelte library is not actually shipped to the browser
Instead of dealing with virtual DOM, it directly deals with an actual DOM

Here is a sample app to compare

Few things you will notice here…

Svelte is directly dealing with HTML, so, unlike JSX there is no need to have a single root
No need to have a wrapper function
The explicit import isn’t required
State management is cleaner without hooks

This for a simpler component might not seem much. But the more complex the component gets, these benefits start making an impact on readability, size of the bundle and overall speed of the application.

So far, based on converting my hobby projects from React into Svelte(SvelteKit) it has been a great experience.

Hope this sparks your curiosity and inspires you to peek into the world of Svelte, now go write some code!

Circuit Breaker/Exponential Backoff Pattern (C#)

This device pictured above, part of all electrical systems(you hope so) has a feature to put a break in electricity supply if something goes wrong.

WHY: Wherever there is overcurrent or short circuit, this prevents further damage to the whole system.

In software the current flowing through the network is the data. If one of the service your app depends on is down or slow, retrying it could cause more damage than solve the problem.

As part of making your application resilient and keeping the relevant services healthy, usually two patterns of retry are clubbed together. Circuit Breaker and Exponential Backoff. In case of failure in service calls, following diagram explains how retry, exponential backoff and eventual circuit break looks like on a timeline.

Here it is re-trying a failing request four times, increasing the delay in calls each time, eventually giving up(break)

Alright, show me the code already…

An example in C# with Polly and Flurl

Don’t worry, you can copy or tinker the code here

Doing this just helped me wrap my head around it a bit better, production quality implementation will always look more detailed.

Real world example of adapter design pattern

Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate.

Nintendo Switch with its default interface works on a smaller portable screen but with an HDMI adapter it also connects to a TV.

C# representation of the same might look like…

Portable interface and its implementation

public interface IPortableDisplay
{
   Stream GetStream();
}
	
public class PortableGameConsole : IPortableDisplay
{
  public Stream GetStream()
  {
   return gameStream;
  }
}

Adapter code…

public interface IHDMI 
{
  Stream GetHDMIStream();
}

public class PortableConsoleHDMIAdapter : IHDMI
{
  private PortableGameConsole _portableGameConsole;
		
  public PortableConsoleHDMIAdapter(PortableGameConsole portableGameConsole)
  {
     _portableGameConsole = portableGameConsole;
  }
		
  public Stream GetHDMIStream()
  {
    return _portableGameConsole.GetStream();
  }
}

Understanding ASP.net core dependency injection types

When adding dependencies in asp.net core project you will see three options

Transient
Scoped
Singleton

Just for my mental note, trying to document it with images

The scenario is very simple, maybe not a true real-world one but whatever gets the point across. There is only one endpoint in a controller, which then calls a service which eventually calls a repository. All these rely on ILogger

In each of these, the change in color indicates a new instance

Hope these images make it easier to remember.

Semantic Clothing

It’s really about semantic HTML, sorry for the confusion. Confusion though is the keyword of this article. Imagine you walk into a clothing store, and sections are marked as head garments instead of hats, shirts are called upper-body garment, pants are called leg garments and socks are called feet garments, essentially everything is a garment. Very confusing indeed.

Now, if your HTML code looks something like below, you are creating a similar confusion for the browsers or any client trying to parse your html.

<div class="header"></div>
<div class="nav"></div>
<div class="section"></div>
<div class="main">
    <div class="post"></div>
    <div class="post"></div>
</div>
<div class="sidebar"></div>
<div class="footer"></div>

Instead it should look like…

<header></header>
<nav></nav>
<section></section>
<main>
  <article></article>
  <article></article>
</main>
<aside></aside>
<footer></footer>

Few reasons why you should do it…

Search engines and screen readers have easier time reading it
Just by making it easier to read the code, improves the maintainability of it

Check out many more here

Checkout the full list of html elements you can use here

Mocking In Unit Tests

Just documenting another concept into a mental model.

Imagine you are preparing for a game of tennis, but you don’t have any opponents to practice with. This is an external dependency.

How do you practice your game, you can’t bounce it of the wall, it will be predictable. An automatic tennis ball machine is what you need.

It will throw balls at you at varying speeds at different angles, much like a real player would. But a human opponent will still surprise you no matter how much you practice playing against a ball machine.

In Test Driven Development mocking frameworks are playing that exact same role, for example replacing an external API dependency. Hard coding values would be like bouncing the ball of a wall for tennis practice. Mock will provide you the ability but a real API at production still might have surprises for you.

I mainly work in .net and here are the tools I use to do testing…

GraphQL vs REST vs gRPC Pizza Analogy

This is not to provide you with any technical internals or implementation details, maybe just to establish a mental model. It might come handy when deciding what to use.

Imagine you are craving Pizza. You have three options…

Order from a pizza place that has preset pizza menu. No customization of size or toppings, that’s REST.

A pizza place that allows you complete customization of size and toppings, that’s GraphQL. Probably will be slower than REST.

The third option is a frozen pizza you have it in your fridge. You already bought the kind you like, that’s gRPC. This is the fastest way you will get your pizza.

And just like Pizza relies on dough, they all rely on HTTP

Two key aspects in which Svelte is different than React (or any other popular library)

Few things you will notice here…

Background

Usage in Software