DEV Community: Johannes Mogashoa

Mistakes Were Made

Johannes Mogashoa — Sat, 18 Oct 2025 21:00:56 +0000

Legacy Legacy Legacy

For many years, .NET Framework has been at the core of many enterprise systems, where some of the very crucial systems we use to this day still run on this technology. Like many other things that come and go, that are discontinued, deprecated, or no longer actively supported, the same can be said for .NET Framework. Though the support policy for the framework is still active and will still be distributed with Windows, many folks have stopped ensuring backwards compatibility for the framework in new tools.

Since the decision to unify the .NET Framework & .NET Core with the release of .NET 5 in 2020, a new .NET version has been released every year, with every second release being an LTS version. So the time has come for some companies to make the difficult & costly decision of how to move into the future with their legacy systems. What is the game plan? How far behind are they? Now, in my opinion, I believe that there are all but two clear paths that can be taken.

Strangler Fig Pattern

Simply put, rebuild the system piece by piece until you have a shiny "new" system. Now, a lot needs to be taken into consideration when going down this path, and best to have a guideline and well-planned execution. One could liken this approach to requiring "surgical" precision, knowing which components to migrate and when, having clear boundaries and understanding each dependency, but of course, do you simply have the know-how to put this strategy into place?
For more context: MS Learn

Full Rewrite

As one would think, this is probably the better road to take, blank canvas and all. Wrong, this path, just like the first, leaves so much room for error, if not more. One could say, if you are the gambling type, this approach is probably for you. There is a higher risk, higher cost, higher requirements and possibly a higher reward as well if executed skillfully.

I guess from the title, you can bet which approach we took.

Ready...Set...Go!

Let the rewriting begin. So a team was assembled that would be responsible for spearheading the redesign, redevelopment, re-everything of the system, and everyone else would follow our lead. The responsibilities included, but were not limited to, choosing of tech stack, choosing of architecture, choosing of infrastructure, and choosing of tools that would be used.

Mistake One: Tech Stack

Language & Framework (BE)

Having been a company that relied heavily on the Microsoft ecosystem and the legacy system being built with C# and .NET, the choice language-wise was basically already made, no room for discussion there. So much of the core data models and structures could be reused with a few minor tweaks here and there, leveraging the new features that came with C# v12 & .NET 8. This seemed really possible and straightforward, language and framework, check. Onto the next thing on the list.

Database + ORM

Already having decided that our BE is C# and .NET, there aren't really a lot of ORM options one can go for, so why not the tried and tested Entity Framework, why not the constantly improving ORM that makes life so much easier for you? Nope. Fair, the original system was built using ADO.NET. Perhaps the aim is to use something similar and perhaps re-use some of the SQL queries with improvements from Dapper, wrong. We not only opted not to use Entity Framework, but we also opted for a NoSQL database as well, Azure Cosmos DB.

Language & Framework (FE)

With re-writing came the great opportunity to relook at the user interface and experience. We could explore and experiment as much as we want. The JS ecosystem has been booming with different libraries, frameworks and meta-frameworks which could really bring new life into how the system looks. Err, wrong! Most of the team members are C# developers and only ever use JS with the likes of JQuery; therefore, having to learn either React, Angular, or Vue is going to be costly and time-consuming.

Enter the "saviour", Microsoft's newest frontend framework, Blazor.

"Blazor is a modern front-end web framework based on HTML, CSS, and C# that helps you build web apps faster."

Sure, why not use Blazor? It makes life easier for the developers who are primarily backend, to work on the frontend as well. Seems like the better choice. So what's next? The UI library. No shade to the long-time standing Bootstrap, but it's 2023 and there are so many other libraries one could use outside of Bootstrap; TailwindCSS, Bulma, Materialize CSS, just to name a few. Forget that for a minute, maybe we can use a Blazor component library to speed up development; there are a few in the market: MudBlazor, Telerik, Syncfusion, Radzen. Ultimately, we go with what we already have a license for, Telerik.

So there you have it, the main components of our tech stack:

Blazor + Telerik
C# + .NET
Azure Cosmos DB + Repository

Mistake Two: Architecture

Having a blank canvas can just as easily break a system as it can make it. You start to think to yourself, if we had a monolithic system that ended up in the position it is now, where only a few can contribute to it because of its fragility and code spaghetti-ness, then we sure best not repeat the same mistake, so let's go for a microservice architecture. Let us have individual services that will be responsible for separate yet not-so-isolated processes that can somewhat run independently of one another.

Microservice Architecture

Easy technical design to go with if all the considerations and requirements are taken into account, and everything matches up.

Do we have a bounded context map that clearly outlines what the different services will be and what their responsibilities will be?
What sort of data management will we have? Will each service have its own database, or will there be a logical separation of a shared database?
How will the services communicate with each other? How will the data flow between them?
How will this be deployed and maintained?
What sort of security will we have?
How will the frontends communicate with the backend services?

Sure enough, every question was answered, or so we thought. So where did it really start to go wrong?

Mistake Three: MVP aka POC

With "everything" taken into consideration, we got to writing the code. We had to prove that this technology can work together and that the architecture was sound. Why not start with a proof of concept that evolves into the minimal viable product? The requirements were set out, and so it began, day in, day out. Pull request after pull request. Demo after demo. One year later, we finally delivered a working MVP that was presented from videos recorded while the system was running on localhost with multiple Visual Studio debugging instances.

Happiness all round, we proved the concept works and the system "runs" on this new technology. Onto the next phase, delivering an actual deployable, "production-ready" version of the system.

Mistake Four: "Fail Fast, Fail Forward"

This is a term thrown around a lot in different environments and ecosystems, and in the development world, it purely means identifying problems quickly(iterate quickly) and learn from them to make the next iteration a lot better. Place your team in a position that allows them to iterate quickly and test out functionality, and see if it works. One word comes to mind: "Agile". Agile + Scrum, why not? 2-week sprints with daily standups and sprint planning.

One of the most important items when wanting to fail fast but fail forward is to ensure everything is tested out in the very beginning, scaffold your solution, and an API or two, deploy to an environment and see with everything hooked up, does it work? You will quickly realise things you may have overlooked, things that may influence how your team will work, how they will deliver on the sprint items...developer experience.

Mistake Five: Developer Experience

With all the above mistakes being made, it led to the biggest mistake of all, crucial yet overlooked by plenty. Developer tools can only do so much to improve the overall experience of the developer when writing code; IntelliSense, debugging, code completion, etc. Yes, they are important, but restrictions placed on developers due to mistakes are just as important. "My laptop is too slow to run the solution", "My laptop is out of memory, I need more RAM", "The build pipelines take close to 8 minutes to build one service", "I'd rather work on my personal machine since it has more power".

Lessons Learnt

The definition of insanity is doing the same thing over and over again and expecting different results

A lot has been learned during the course of this rewrite, and we would surely be insane to do the same in future and expect success. It is crucial to understand the requirements of the path you are undertaking and not rush an outcome due to consequences that ought to have been considered upon planning. Lessons to take into the next journey:

"Fail to plan, plan to fail" - without clear goals, architecture, and processes, you’ll waste time, mismanage resources, and deliver unstable systems.
Understand your team's capabilities (strengths & weaknesses) - knowing and understanding your team's dynamics allows you to allocate work accordingly.
Understand the tech you're backing - the newest shiniest tool isn't always the sharpest tool in the shed or the best tool for the job. Take time to understand the applicable scenarios that work best for the tool, not try to bend it to work best for you.

One major lesson I learned is, awareness without action is complicity — seeing the car headed for disaster and saying nothing until it crashes doesn’t absolve you.

You plan intelligently, expect failure, detect it fast, and evolve forward.

Cheers ✌🏽

I built a PWA - The Blazor WASM way

Johannes Mogashoa — Thu, 04 Jan 2024 11:55:29 +0000

Background

As a software developer, one is bound to come across the weird requirement from a client, "I want a mobile app". Yeah, sure no problem, let me get my dev environment setup correctly. You are bound to reach for something like Flutter or React Native or Ionic for a single codebase cross-platform approach because why not right? Then your client says, "But I am not willing to deal with the stores, can't we get around that?" Of course, we can, why not build a PWA. Users can save it onto their phone from the web and we can have extra native features like push notifications etc. "Great! Let's go for it"!

Getting into it

Well building a PWA is not too far off from building any other web app like a SPA am I right? Pick and choose from React, Angular, Vue and the like...
Well issue one is that I am a .NET developer. Oh boy!
Easy solution: .NET's crown jewel framework, BLAZOR.

Time to build

With building the app there were a few things to consider:

Will the app need a backend? (yes)
Is authentication required? (yes, I want to use Microsoft)
What are the core functionalities of the app? (more web-like features)
Feasibility of building a PWA over Native App? (cheaper to deploy)

With all those considered the building began. Well with the app requiring a backend and authentication, I reached for the Blazor WebAssembly template with the Co-Hosted & PWA options enabled. Authentication from there was an easy choice, "Individual Accounts" or "Microsoft Identity Platform". Well with an existing Microsoft Active Directory it makes perfect sense to go for Microsoft Identity Platform. So right at the end this what the options looked like...

Easy enough going from there was simply configuring all the relevant Microsoft Entra ID applications on Azure for the Client app and the Server app and letting Visual Studio do all the heavy lifting of configuring everything for me. The end result looks very similar to how any Blazor WASM app with ASP.NET Core Hosted solution looks like. Only a few minor differences due to the "PWA" option that was selected which means the client project had a few more files specifically in the wwwroot folder:

service-worker.js
service-worker.published.js
manifest.json
icon-512.png

What next?

I finally have a running project which I can actually install on my device, I mean Edge tells me I can.

That's the easy part done. Fast forward all the design implementations and coding out all the features, comes the time to finally deploy the app to a test environment and test it on an actual mobile device. Easy enough I deploy the server project to an IIS server like I would a normal AspNet Core app and it runs smoothly. I then update the URLs in Azure Entra ID for the authentication to work and Bob was my uncle, or so I thought. Enter classic tale of a developer; "It worked on my local", I now ran into a few issues that I had to resolve, and I learned something while doing so.

PWA Learnings

The tale of building a PWA is that it's meant to be cross platform and not have any issues but oh it did.

DateTime compatibility

Turned out Android & iOS do not format the date and time the same way and the iOS format was not compatible with C#'s DateTime type.

Solution: build a helper method that will parse the datetime input correctly.

public static DateTime GetCorrectDateTime(string inputDate) 
{

    DateTime _newDate;
    string format = "dd/MM/yyyy HH:mm:ss";
    try
    {
        // Try to parse using the default format and culture
        _newDate = DateTime.Parse(inputDate);
    }
    catch (FormatException)
    {
       // If the default format fails, try to parse using the specified format and culture
       _newDate = DateTime.ParseExact(inputDate, format, CultureInfo.InvariantCulture);
    }

    return _newDate;
}

Install prompt

When a web app is a PWA, the browser picks up on that and is able to prompt the user to install the app onto their device, turns out not all browsers support that. Ooops!

Solution: there is none, 👀 just ensure on iOS the user is using Safari and on Android they use Chrome. Read more here...

Authentication state

When the user hadn't been using the app for some time and the Azure token expires and they open up a page that makes an API call, it would fail. This is because the internal API calls have a HttpMessageHandler which is BaseAddressAuthorizationMessageHandler which extends the AuthorizationMessageHandler class which tries to add the authentication token to the request header and when that fails an exception is thrown. If not handled the app breaks. 🤯💥

Solution: use the TryGetToken method on the AccessTokenResult to get the user's authentication token and if that fails redirect to login before making any calls using the HTTP Client.

@code {
  private const string Prisma = "Prisma";
  public bool Loading { get; set; } = true;

  protected override async Task OnInitializedAsync()
  {
        var accessTokenResult = await AccessTokenProvider.RequestAccessToken();

        if (!accessTokenResult.TryGetToken(out var token))
        {
            accessTokenResult.InteractionOptions.TryAddAdditionalParameter("prompt", "login");

            NavigationManager.NavigateToLogin(accessTokenResult.InteractiveRequestUrl, 
                accessTokenResult.InteractionOptions);
        }

        Loading = false;
    }
}

Hopefully in future releases there will be a much more graceful way of handling this issue.

Deploying new updates

Well since this is a PWA I should just be able to deploy the changes and not have to worry about the user having to update the app manually like they would via the store. Yes & No. Huh? Yes you can deploy the changes but they will not be able to see the changes until they close ALL active instances of the app on their device. This means the actual installed version and any open tabs in their browser need to be closed before updates can happen.

Solution: Why not just force the app to use the updated version...enter this line of code in the service-worker.published.js. Blazor actually copies all the contents in the service-worker.published.js into service-worker.js when building for production hence we make the change in there.

    // Activate the new service worker as soon as the old one is retired.
    self.skipWaiting();

The line above is added like so:

async function onInstall(event) {
    console.info('Service worker: Install');

    // Activate the new service worker as soon as the old one is retired.
    self.skipWaiting();

    // Fetch and cache all matching items from the assets manifest
    const assetsRequests = self.assetsManifest.assets
        .filter(asset => offlineAssetsInclude.some(pattern => pattern.test(asset.url)))
        .filter(asset => !offlineAssetsExclude.some(pattern => pattern.test(asset.url)))
        .map(asset => new Request(asset.url, { integrity: asset.hash, cache: 'no-cache' }));
    await caches.open(cacheName).then(cache => cache.addAll(assetsRequests));
}

Outro

The question that is always asked around Blazor is, "Will it ever replace Angular or React or Vue?" Honest truth? Nope it will not but I will say that it is a really great alternative to using those frameworks especially if you are a dotnet developer and want to continue using C# even on the frontend. I would definitely use Blazor again. 🎉

Useful Links

Web Dev: https://web.dev/learn/pwa/
MDN: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
PWA Install Criteria: https://web.dev/articles/install-criteria- Lighthouse Report: https://developer.chrome.com/docs/lighthouse/pwa/load-fast-enough-for-pwa
Microsoft Learn: https://learn.microsoft.com/en-us/aspnet/core/blazor/progressive-web-app?view=aspnetcore-7.0&tabs=visual-studio
Auth with Entra ID: https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-microsoft-entra-id?view=aspnetcore-7.0
Pushing updates: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

Setup project with Next.js, Prisma, tRPC, & NextAuth

Johannes Mogashoa — Fri, 15 Apr 2022 17:04:20 +0000

Background

Recently I was working on a small project where I could explore using technologies I haven't really used that much and put it all to practice. The aim was to build a clone of Kubool which is a platform that allows you to send anonymous messages. And so I got started.

My initial stack choice was:

NextJS
Prisma
Postgres from Railway
Typescript
NextAuth
Formik + Yup
Tailwind CSS
Vercel

I went ahead built the first basic version of the clone and deployed it on Vercel. You can check it out here: https://anony-sender.vercel.app. Later on I decided that "Nope let me rebuild the API endpoint to include tRPC which is a tool that provides you with end-to-end typesafe APIs. Adding tRPC to the project was a mission but I prevailed and thought why not share the steps of creating a project from scratch with tRPC. Links to the respective sites will be provided at the bottom.

Steps for setting up

The project setup will make use of the technologies I mentioned above. Prerequisites:

Node.JS
Text/code editor (I prefer VS Code)
Preferred command line tool (Windows Terminal)
Git

Step 1: Create & clone repo from starter template

As I have come to focus my interest in building projects with the above mentioned technologies, I went ahead and created a starter template for myself whenever beginning a new project. So let's build on top of that starter template.

Link to starter template: https://github.com/JohannesMogashoa/nextjs-prisma

After creating and cloning your repo to your local machine. You may open up that project in your command line tool. Go ahead and install the dependencies by running npm install or yarn install

Step 2: Adding tRPC to the project

You can head over to the official tRPC site: https://trpc.io/ to take a look at their documentation.

At this point you can either use the command line tool or VS Code's integrated terminal.

yarn add @trpc/client @trpc/server @trpc/react @trpc/next zod react-query superjson ws

Next Steps:

Create a backend folder in the root of your project
Create a utils and routers folder inside the backend folder
Inside the routers folder create an index.ts file
Inside the utils folder create a context.ts and createRouter.ts file
Inside the lib folder, create a trpc.ts file
Create a trp folder inside of pages/api/, then add a [trpc].ts file.

The paths to files mentioned above should be as follows:

- backend/routers/index.ts
- backend/utils/context.ts
- backend/utils/createRouter.ts
- lib/trpc.ts
- pages/api/trpc/[trpc].ts

Step 3 - Set Up Backend Folders

backend/utils/context
Since the app is making use of prisma and nextauth, these "values" can be passed through to the rest of the tRPC routes using the context for easy accessibility throughout.

import { getSession } from "next-auth/react";
import * as trpc from '@trpc/server';
import * as trpcNext from '@trpc/server/adapters/next';
import { NodeHTTPCreateContextFnOptions } from '@trpc/server/adapters/node-http';
import { IncomingMessage } from 'http';
import ws from 'ws';
import {prisma} from "@/lib/prisma"

Copy the above import statements into the context.ts file then copy the below section of code.

export const createContext = async ({
    req,
    res,
}:
    | trpcNext.CreateNextContextOptions
    | NodeHTTPCreateContextFnOptions<IncomingMessage, ws>) => {
    const session = await getSession({ req });
    return {
        req,
        res,
        prisma,
        session,
    };
};

export type Context = trpc.inferAsyncReturnType<typeof createContext>;

backend/utils/createRouter
Copy the below code into the createRouter.ts file

import { Context } from "./context";
import * as trpc from "@trpc/server";

export function createRouter() {
    return trpc.router<Context>()
}

backend/routers/index
In this file, the tRPC App Router is created with all the different routes you would like to have. The below example is if you would like to have ALL your routes in the same file.

import { createRouter } from '@/backend/utils/createRouter';
import superjson from "superjson"
import { z } from 'zod';

export const appRouter = createRouter()
    .transformer(superjson)
    .mutation('set-username', {
        input: z.object({
            username: z.string(),
            email: z.string().email()
        }),
        async resolve({ ctx, input }) {

            await ctx.prisma!.user.update({
                where: {
                    email: input.email,
                },
                data: {
                    slug: input.username,
                },
            })

            return { success: true, message: "Username set successfully" }
        }
    })
    .query('get-user', {
        input: z.object({
            email: z.string().email()
        }),
        async resolve({ ctx, input }) {
            const user = await ctx.prisma!.user.findUnique({
                where: {
                    email: input.email,
                },
            })

            return { success: true, user }
        }
    })

// export type definition of API
export type AppRouter = typeof appRouter;

As you can imagine, the above code will become more and more as you add other routes and their respective logic. So a better way would be to group routes and place in another file then import those routes into the appRouter. Create another file i.e. userRoutes.ts inside the backend/routers folder. The refactored code would like something of the below nature.

// backend/routers/index.ts

import { createRouter } from '@/backend/utils/createRouter';
import superjson from "superjson"
import { userRouter } from './userRouter';

export const appRouter = createRouter()
    .transformer(superjson)
    .merge('user', userRouter)
// other merged routes here

// export type definition of API
export type AppRouter = typeof appRouter;

// backend/routers/userRouter.ts

import { z } from "zod"
import { createRouter } from "../utils/createRouter"

export const userRouter = createRouter()
    .mutation('set-username', {
        input: z.object({
            username: z.string(),
            email: z.string().email()
        }),
        async resolve({ ctx, input }) {

            await ctx.prisma!.user.update({
                where: {
                    email: input.email,
                },
                data: {
                    slug: input.username,
                },
            })

            return { success: true, message: "Username set successfully" }
        }
    })
    .query('get-user', {
        input: z.object({
            email: z.string().email()
        }),
        async resolve({ ctx, input }) {
            const user = await ctx.prisma!.user.findUnique({
                where: {
                    email: input.email,
                },
            })

            return { success: true, user }
        }
    })

When you have added all the above code consider yourself temporarily done with the backend/ folder and you can now move onto the other files in the other folders.

lib/trpc.ts

import { AppRouter } from '@/backend/routers';
import { createReactQueryHooks } from '@trpc/react';

export const trpc = createReactQueryHooks<AppRouter>();

pages/api/trpc/[trpc].ts
This portion is the official setup of the tRPC API endpoint that will handle requests made to your defined routers in the App Router.

import { appRouter, AppRouter } from '@/backend/routers';
import { inferProcedureOutput } from '@trpc/server';
import * as trpcNext from '@trpc/server/adapters/next';
import { createContext } from '@/backend/utils/context';

// export API handler
export default trpcNext.createNextApiHandler({
    router: appRouter,
    createContext,
    onError({ error }) {
        if (error.code === 'INTERNAL_SERVER_ERROR') {
            // send to bug reporting
            console.error('Something went wrong', error);
        }
    },
});

export type inferQueryResponse<
    TRouteKey extends keyof AppRouter["_def"]["queries"]
    > = inferProcedureOutput<AppRouter["_def"]["queries"][TRouteKey]>;

At this point you have completed adding the necessary code into all the files you have created. Now moving onto the final implementation of tRPC in the pages/_app.tsx file.

Step 4 - Edit pages/_app.tsx file

Navigate to the pages/_app.tsx file and make the following changes to it:

Remove the export default MyApp line and paste the following code

// Initializing TRPC server on the Next.js server
import { withTRPC } from "@trpc/next";
import type { AppRouter } from "@/backend/routers";

// Check to see the current environment then generate the appropriate URL
function getBaseUrl() {
    if (process.browser) return ""; // Browser should use current path
    if (process.env.VERCEL_URL) return `https://${process.env.VERCEL_URL}`; // SSR should use vercel url

    return `http://localhost:${process.env.PORT ?? 3000}`; // dev SSR should use localhost
}

export default withTRPC<AppRouter>({
    config({ ctx }) {
        /**
         * If you want to use SSR, you need to use the server's full URL
         * @link https://trpc.io/docs/ssr
         */
        const url = `${getBaseUrl()}/api/trpc`;

        return {
            url,
            /**
             * @link https://react-query.tanstack.com/reference/QueryClient
             */
            // queryClientConfig: { defaultOptions: { queries: { staleTime: 60 } } },
        };
    },
    /**
     * @link https://trpc.io/docs/ssr
     */
    ssr: false,
})(MyApp);

Phew!!!! That was a lot of code. At this point in time, you should be able to connect your "frontend" to your "backend" using the tRPC client instance created in your lib/trpc.ts file.

Step 5 - Using tRPC

Now that everything has been implemented on the backend, we can now use the client instance wherever we use to use it. Let's try getting a user from the database using tRPC's hooks that are using React Query under the hood.

import { trpc } from "@/utils/trpc";
import { useSession } from "next-auth/react";
import React from "react";

const UserComponent: React.FC = () => {
    const {data: session} = useSession()
    const {data} = trpc.useQuery(["get-user", { email: session?.user?.email as string}]);

    return (
        <div>
            <h1>{data?.user?.name}</h1>
            <p>{data?.user?.email}</p>
        </div>
    );
};

export default UserComponent;

At this point, you can happily say you have implemented tRPC into your NextJS application.

Outro

Believe me or not, I had written and completed the app using Next's built-in API routing and handling system but the code was messy, had typecasting all over the place in order to mimic some sort of end-to-end type safety between the backend and the client. I have found tRPC to be a really useful tool and look forward to using it more often. If you would like to checkout a github repo that uses tRPC without NextAuth take a look at Roundest by Theo Browne

Building My First Side Project - Part 1

Johannes Mogashoa — Sun, 16 Jan 2022 06:49:56 +0000

Introduction

So it has been a while since I got introduced to web development and the community. Wrote my first line of simple code back in 2016 but only formerly started coding in 2020 when I was doing my first year in varsity. I have been contemplating this whole side project thing for making my portfolio look appealing to prospective employers. Finally found a simple project to do: A Student Accommodation Booking Portal.

Why??

I was recently trying to apply for accommodation and one of the residences didn't have a booking system. They were simply using a Google Forms to collect user information and to process everything. So I thought why not build a simple web app for them.

Then What??

In doing so, I opted for the following technologies when building this project:

Core Technologies:

React/NextJS
Tailwindcss
Prisma
TypeScript
SQLite DB
NextAuth

Experimental Technologies:

These are technologies that I am interested in learning/working with but currently unsure.

tRPC
GraphQL
Zustand

Features

This particular platform will include the following features:

Authentication (Google, Facebook, Email Magic Link) - Powered by NextAuth
Role-based Auth
Profile Creation and Editing
Viewing of all the properties
Application for accommodation and editing of application
Application Status tracking
Space Availability tracking

Progress?

So far not a lot has been done except for the following:

project initialization with typescript
adding tailwindcss
adding and initializing prisma and schema
adding nextauth
setting up Google OAuth Credentials

Current progress can be checked out here 👉 Github Link

For now it's back to coding. Part 2 coming soon... cheers 🤘🤘