.NET Core has been ported to UNIX-like systems a while ago. Some projects have started migrating to it, some started from scratch with it. This article will describe the pitfalls based on my professional experience related to micro/nano/service hype.

• What's wrong with microservices?
• Would my startup microservice system succeed?
• Can I be sure that in the end the system is operational?

The answer for all of the above - it depends. And depends on several important things that usually people don't like to dive too deep into.

The first thing is - microservices require waterfall planning. That might sound terrifying, especially with all of the hype around Agile but believe me - if you don't know how the system with 20+ micro systems will work together you'll end up with spaghetti microservices. They'll be communicating through HTTP to keep it simple, they will depend on each other, and if you will be lucky enough - you'll end up with not really reliable but working from time to time system that can handle not that much load as you would expect from microservices.

Why does it like this?
- Lack of planning and technical clarifying at the beginning.
- Lack of  planning across teams during development.
- Lack of understaning how the system will work at the end.

The system must be incredibly clarified before you do the microservice approach from scratch. That's it. Continuous technical grooming across the all teams in several domains is a key.

I'm used to be using async/await keywords in .NET. It increases the throughput of the services I'm working on dramatically.  At some point, using async gained me 10x performance improvements in terms of users throughput, by simply applying asynchronous overload to the critical part of a software. But if it's so simple to use and at the same time so powerful - how does it work behind the scenes? Well, not that simple. The keywords I love so much for their simplicity are just syntactic sugar and translated on a compiler level to something called Async State Machine.

Example

Let's dive a bit deeper and rely on an example. I will use simple program that tries to get the data from
Dictionary if the key is found, if not I await with
Task.Delay and after that initializing it for later use.

That's how I see the code in IDE:

private readonly Dictionary<string, decimal> _dictionaryCache = new Dictionary<string, decimal>();

public Task<decimal> GetValueFromCacheAsync(string key)
{
    if(_dictionaryCache.ContainsKey(key))
    {
        return Task.FromResult(_dictionaryCache[key]);
    }

    return InitCacheLazyAsync(key);
}

private async Task<decimal> InitCacheLazyAsync(string key)
{
    await Task.Delay(1000);
    var value = 11.11m;

    _dictionaryCache.Add(key, value);

    return value;
}

And that's what the code looks like on a compiler level:

using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
using System.Threading.Tasks;

class StateMachineCompiler
{
    public Task<decimal> GetValueFromCacheAsync(string key)
    {
        return _dictionaryCache.ContainsKey(key) ? Task.FromResult(_dictionaryCache[key]) : InitCacheLazyAsync(key);
    }

    private Task<decimal> InitCacheLazyAsync(string key)
    {
        var stateMachine = new InitCacheLazyStateMachine();
        stateMachine.RelatedTo = this;
        stateMachine.Builder = AsyncTaskMethodBuilder<decimal>.Create();
        stateMachine.State = State.Created;
        stateMachine.Key = key;
        stateMachine.Builder.Start(ref stateMachine);

        return stateMachine.Builder.Task;
    }

    private struct InitCacheLazyStateMachine : IAsyncStateMachine
    {
        public State State;
        public AsyncTaskMethodBuilder<decimal> Builder;
        public string Key;
        public StateMachineCompiler RelatedTo;
        private TaskAwaiter _taskAwaiter;

        // Task state management.
        void IAsyncStateMachine.MoveNext()
        {
            // ...
        }
    }

    enum State 
    {
        //...
    }
}

Wow! No more async await keywords in our code, but does it mean we're running synchronous code? As always in software engineering it depends on a context.

By default .NET runtime will try to execute the Task straight away if it could - synchronously. The reason for that is to not overhead with queuing and scheduling management if the code is actually can perform synchronously. But even on synchronous method marked with async (without await inside) state machine will be generated anyway and the code which could potentially be inlined and executed much faster will be generating additional complexity for state machine management. That's why it's so important to mark methods as async if and only if there is await inside.

So let's take a closer look at State Machine compiler generated contract:

public interface IAsyncStateMachine
{
    //
    // Summary:
    //     Moves the state machine to its next state.
    void MoveNext();
    //
    // Summary:
    //     Configures the state machine with a heap-allocated replica.
    //
    // Parameters:
    //   stateMachine:
    //     The heap-allocated replica.
    void SetStateMachine(IAsyncStateMachine stateMachine);
}

The main method state machine operates on is
void MoveNext(); An interesting part that it returns nothing because mutates the state by reference. By design it's relying on awaiters completion and what it actually does is well described in docs:
Moves the state machine to its next state.

StateMachine itself may have three different states to track Task status:

enum State
{
    Completed = -2,
    Created = -1,
    Awaiting = 0,
}

Once AsyncTaskMethodBuilder hits Start command state machine's
MoveNext method is being executed.

What MoveNext does is state management, it checks if awaiter is completed or not and changes the state of state machine and/or Task. Once state machine is finally able to mark the task as completed it calls
Builder.SetResult(); and it's done.

Here is a basic flow for this example:

GetValueFromCacheAsync is now initializing state machine (2) and starts Task processing/scheduling (3) for the first time.

Once task processing's being started the runtime checks if task can be executed synchronously and if so Task.ExecuteEntry is called, Task is marked as completed, and we got the task fulfilled with result straight away.
If the task can't run synchronously - that's where by default ThreadPool queuing comes in play.

ThreadPool queuing operates on events and callbacks as well as asynchronous operations. There are two types of processing - CPU bound and I/O bound. On truly asynchronous operations such as writing to Disk or making Network requests .NET waits to be notified that native process is completed and assigns a thread to continue processing the result of a native service. That's what called I/O bound operations. For CPU bound there could be a thread to process the result in a background. For a better understanding of how this is possible I recommend to read article by Stephen Cleary - there is no thread.

So once ThreadPool is notified about completion of asynchronous operation it notifies Async State Machine again and MoveNext() is executed second time.

MoveNext checks if awaiter is completed and since it is - sets the result of the task and it's done. The state machine exits and .NET continue processing.

private struct InitCacheLazyStateMachine : IAsyncStateMachine
{
    public State State;

    public AsyncTaskMethodBuilder<decimal> Builder;

    public string Key;

    public StateMachineCompiler RelatedTo;

    private TaskAwaiter _taskAwaiter;

    public void SetStateMachine(IAsyncStateMachine stateMachine)
    {
        // Obsolete contract.
    }

    void IAsyncStateMachine.MoveNext()
    {
        State currentState = State;
        decimal result;
        try
        {
            TaskAwaiter awaiter;
            if (currentState != State.Awaiting)
            {
                awaiter = Task.Delay(1000).GetAwaiter();
                if (!awaiter.IsCompleted)
                {
                    State = State.Awaiting;
                    _taskAwaiter = awaiter;
                    var stateMachine = this;

                    // Schedules the state machine to proceed to the next action when the specified awaiter completes.
                    Builder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);

                    return;
                }
            }
            else
            {
                awaiter = _taskAwaiter;
                _taskAwaiter = new TaskAwaiter();
                State = State.Created;
            }

            awaiter.GetResult();
            result = new decimal(1111, 0, 0, false, 2);
            RelatedTo._dictionaryCache.Add(Key, result);
        }
        catch (Exception ex)
        {
            State = State.Completed;
            Builder.SetException(ex);

            return;
        }

        State = State.Completed;
        Builder.SetResult(result);
    }
}

Conclusion

• Do not mark methods async if there is no await inside.
• The code we write so tidy and clean could be a mess behind the scenes - it's always good to strive for knowledge and understand the underlying complexity of a software.

I haven't touched in this article error handling parts as well as I didn't want to dive too deeply inside. I may touch it in my future posts, though.
Please feel free to join the discussion or give me a heads up on any part you're interested in.

References:

1. TaskScheduler QueueTask GitHub link
2. Task ExecuteEntry GitHub link
3. There is no thread

Choose Flutter

Disclaimer

Information in this post is just my personal feelings which could be different from yours.

Compare frameworks

I never was an Android developer but from time to time I tried to create some apps for my mobile phone. I tried several frameworks and technologies: Xamarin, Nativescript, React Native, and finally Flutter. What I can say - the fastest boost for me as a newcomer was indeed in Flutter. The community is so big (93k stars on GitHub at the moment) so you can get almost anything you need out of community for your Android application.

For example I required my app a calendar to show the events based on the dates. With the Flutter community that was the smoothest process I could even imagine - there are several great calendar widgets on GitHub completely open-source and free, nevertheless, very powerful and customizable. So I'm a complete rookie on the Dart/Flutter development was able to complete a calendar feature in a matter of time (a few hours to be honest).

Check the following community list:

Solido/awesome-flutter

An awesome list that curates the best Flutter libraries, tools, tutorials, articles and more. - Solido/awesome-flutter

SolidoGitHub

I tried to do the same with Xamarin, React Native or NativeScript - unfortunately only React Native is outstanding with its community and perhaps it's just my feeling but there are no that much good and customizable components for the others.

Xamarin has XML structured code style for UI which for me is very painful to develop, no hot reload, debug of components isn't easy, MVVM approach is just a mess. IMO it's the worst thing I've ever tried.

NativeScript is cool if you have some experience with Angular but again it's not so widely popular so you can have some difficulties finding a component out of community.

So let's take a look at Flutter vs React Native:
I'd prefer Flutter for its Dart language which is strongly typed out of the box and for its strong relation to Material Design guidelines. The way both of the frameworks are structured is almost the same - you're writing UI, styles, and logic in the same files, arranging the components as they will appear on the UI and adding callbacks. The difference comes in the development environment - Flutter has outstanding extensions for VS Code though I was able to quickly and painlessly debug my app, check the components in runtime or even make some performance profiling! Also worth mentioning that Flutter is great at resolving dependencies through pub.dev and has clean and intelligible
pubspec.yaml where you can customize the app.

The main point of success of the framework as for me is how far I can go in development and how many difficulties I'll be facing during the process. Flutter is easy and powerful so if you just as I didn't have a chance to touch it you'll be able to get up to speed in several days. Also if for some reason you need to dive deeper you can succeed in that due to such a great community that you'll definately find good and useful during the development.