DEV Community: Mikhail Kedzel

Creating a blockchain based digital passport

Mikhail Kedzel — Mon, 07 Aug 2023 02:10:14 +0000

Our client

Proof of Meet(POM) is what started as a hackathon project and grew into a full-scale startup. We worked with the client from the beginning, supporting them at every step with savvy developers. Our expertise went way beyond just code, as we saw the business value as well and were able to connect that to tech.

Project description

POM is a Polygon blockchain-based digital passport (a DID wallet), used to share credentials, such as identity and employment history.

Working in a tight timeframe, we had to pick the right tools to develop bug-free code while being extremely agile. The frontend stack was simple yet efficient — TypeScript & NextJs. This allowed us not to spend any time configuring the boilerplate and get straight to work. At first, we didn’t have a designer, so our team used Tailwind — a performant CSS framework for the web, which also has a component library(TailwindUI).

As our Decentralized Identity(DID) provider, we used PolygonId, which enables you to build trusted and secure relationships between users and dApps, following the principles of self-sovereign identity and privacy by default. PolygonId allows users to use zero-knowledge proofs to interact with smart contracts, solving the "trust " problem in web3.

As POM is scaling, we’re continuing to support it and growing our development team with them. Attracting skilled talent is extremely hard for a startup, but at MiKi, we can add up to 5 talented developers to the team in a matter of 4 days.

The result

Working together, we created a stunning MVP for POM, which won multiple hackathons and got the attention of investors. We won EthSeoul2023, the Polygon DevX hackathon, and more.
In the future, we plan to support POM even more and help them develop awesome functionality.

How to build the largest web3 community in Korea

Mikhail Kedzel — Thu, 03 Aug 2023 01:35:02 +0000

How to build the largest web3 community in Korea

Today we’re launching the first episode of MiKi Digital’s Web3 podcast. And our guest is Jordan Smith, the founder of the largest web3 community in South Korea — SojuDAO. We had a great chat with him, talking about his journey, challenges, and plans for SojuDAO. Also, Jordan is currently working on a stealth startup that aims to disrupt the web3 professional social network industry.

Tune into the podcast to learn more about it as well!

This article will briefly summarize the podcast, condensing Jordan’s main points.

Getting into crypto

After leaving university, Jordan worked for many big techs in Silicon Valley and Wall Street but always felt it wasn’t for him. Around 2017, he became interested in crypto and, in 2021, became full-time in crypto, working with a little network called Terra. It was his first introduction to Korea’s vibrant crypto culture. The Terra crash didn’t discourage him but did quite the opposite.

“ *What it showed me is the power of Web3 and the power of community and in building something meaningful. While I was hurt financially, it actually just gave me a little bit more fire to bounce back and want to build something.” — Jordan*

Starting SojuDAO

Jordan moved to Korea in 2022 to live for a couple of months, and that’s when SojuDAO began. It started as a little group chat with Jordan and his friends, with the name being inspired by a famous Korean drink — Soju!

The community grew organically as Jordan introduced it to more people. Next, they hosted a social event, which was just a dinner. Over the year, community members were sponsoring other events, seeing the power in the community. The idea was received well in Korea since all the events are usually in professional settings, but SojuDAO creates relaxed events where people are better able to connect.

“ *From the feedback that I’ve gotten is our specialty that has come from throwing events consistently is that people are able to really build new relationships and forge new partnerships in these events.” — Jordan*

So the first members of SojuDAO weren’t only foreigners, many Koreans appreciated the new way of organizing events. Talking about the future, Jordan says that while the roots of SojuDAO will remain in Korea, it will expand to other regions. In fact, SojuDAO already set up events in Tokyo, Hong Kong, and Paris. So SojuDAO will continue to evolve on a global landscape bringing more and more people together.

Changing Social Networking in Web3

Our chat got really interesting when we started talking about the future of social networking in web3. Jordan is working on a secret startup to change the professional social network industry. Jordan was open about his issues with existing platforms like LinkedIn. He shared his frustration with the platform’s move towards sales and away from building deep connections.

“ *I think that the reason why LinkedIn kind of sucks now is because of people like me have multiplied over the last four years. The former self, my former self. Like it’s a sales tool. It’s no longer a tool to like focus on your deep connections.” — Jordan*

That’s where POM(Proof of Meet) comes in — a stealth-mode startup that Jordan is working on right now. It’ll enable people to have better social experiences. Jordan believes people are still lonelier than ever in a world where we have many ways to connect.

In web3, most people use Telegram to connect, but it lacks a lot of data about the person. So your connection can be easily forgotten. Jordan aims to build synergy between platforms like Telegram or Twitter, and POM to make creating meaningful connections easier.

“ *We’re not necessarily trying to get people to stop using Twitter or Telegram, but we want to enable people to use them better, to improve the relationships that mean something to them or give them an opportunity to find new relationships.” — Jordan*

The main point of POM is that it focuses on real-life connections. Since as Jordan said:

“ *I think that may or may not be a contrarian opinion that most of the important relationships that you make are from in-person interaction.” — Jordan*

Overall thoughts on web3

Regarding web3 trends, Jordan says that restaking and web3 socials can be the next big thing in web3. As for the issues in web3, Jordan believes UX to be a major one. Since it’s still tough for people outside of the industry to get into web3 apps. You should always build apps with your users in mind.

“ *Most of the things are there to try to make a seamless experience, but we just have to build tools with the end user in mind.” — Jordan*

P.S. If you have any suggestions regarding the podcast or want to be the next guest feel free to contact us at our website or book a call.

Crafting the perfect token launchpad - technical description

Mikhail Kedzel — Mon, 31 Jul 2023 10:11:38 +0000

Recently, at MiKi we've created a token launchpad for one of our clients. The project is under NDA, so we can't tell you much. But still, we'll try our best to describe our approach when it comes to building a simple, yet impressive token launchpad on Ethereum blockchain.

Our main requirements for a launchpad were

Speed of development - we had to meet tight deadlines
Ease of future support - the app had to be maintanable with clean, clear code
Stability - the app had to be fault-tolerant, we couldn't have even the slightest downtimes
Blazing-fast loading - if the app loads too long, it'll definitely frustrate our buyers

Let's discuss every part of the app, and what choices we made to meet all the requirements

Frontend

We picked NextJS as the framework, since it has huge user adoption, vast documentation and community support. In web3 as well, there are many libraries specifically built for NextJS or React(NextJs is built on top of React). For example, Moralis - a famous library to integrate Web3 into your app, has a lot of tutorials for specifically NextJS. As it's very easy to handle authentication there and intergate next-auth(authentication library for NextJS) with Moralis.

Compared to regular React, NextJS supports server-side rendering which makes your website load up to 5x times faster. For reference, here's the performance metrics for a typical React app

And here's the data for a NextJS app

Crazy difference, right?

Blockchain integration library

We've picked the frontend framework, now we have to decide how to integrate our frontend with Ethereum blockchain and our smart contracts.

Moralis is a great choice if you want to get going very fast, since it's a rather high level of abstraction. But it comes at a cost of limited customization. Even thought the deadlines were short, we still needed an extensible library which would allow future changes.

We chose ethers - the tried and true library for interacting with Ethereum blockchain and it's ecosystem on the frontend. It's mostly used to intergate with wallets, so has first-class MetaMask support.

A worthy metion is viem - we're using it on our current project and it's working flawlessly. Viem is still new, so using it might be harder than ethers, as there's less comunity support. But Viem addresses many flaws ethers had like type safety.

Doing it the React way

We've also used wagmi - a collection of React Hooks containing everything you need to start working with Ethereum. Wagmi works perfectly with ehters, as it uses ethers under the hook. While wagmi wraps some trivial functionality of ethers to provide you a simple interface, you'll still need to use ethers directly in some cases.

If you want to read more about working with smart contract on the Frontend - check out our article where we go in depth and provide some code snippets https://dev.to/miki-digital/working-with-smart-contract-on-the-frontend-3mem

Backend

We had to implement KYC so a backend was necessary. We could've just stored the KYC on the blockchain, but we weren't sure how large would it get in the future, so opted for a database MongoDB.

As the BE framework - we still used NextJS. It has a minimalist, yet powerful way of writing serverless backend. You can easily run the backend locally, and deploying it is straight-forward as well thanks to vercel. Opossed to bigger providers like AWS, GCP and Azure, on Vercel you can deploy your whole app(backend and frontend) in a few minutes.

The syntax is exteremely simple as well, you just need to declare a handler function for an api route, and handle the logic in there. For example, an API route for fetching balance of a smart contract from etherscan would look like this:

export default async function handle(req: NextApiRequest, res: NextApiResponse) {
  if(req.method === 'GET') {
    const resp = await fetch(`https://api.etherscan.io/api?module=account&action=balance&address=${process.env.NEXT_PUBLIC_CONTRACT_ADDRESS}&tag=latest&apikey=${process.env.ETHERSCAN_API_KEY}`);
    const json = await resp.json();
    res.json(json);
  } else {
    throw new Error(
      `The HTTP ${req.method} method is not supported at this route.`
    );
  }
}

Using Serverless will help us save money, since Serveless only bills you for the number of requests, not the server uptime. Most of our audience were in Korea, so at night there was barely any traffic. Compared to a normal server, Serverless is also fully managed so you don't have to configure the infrastructure - Serverless scales up and down by itself, so you can forget about trying to guess the capacity of your server and allocate enough CPU/Memory/etc. for it.

Connecting to the database

The default solution when it comes to MongoDB and NodeJS is using mongoose, but we believe there's a better choice - Prisma.

Prisma is a next-generation Node.js and TypeScript ORM. While originally made for SQL, it supports MongoDB. The main difference is that Prisma has a custom syntax for schema and a separate file for them - schema.prisma. It has type-safety by default and a rich query builder as well. Functionality is similar to Mongoose; the only difference is that Prisma has Relation filters, while Mongoose doesn't have a dedicated API for it. This means that dealing with relations in Prisma is pretty simple, while you'll have to think of complicated queries in Mongoose. It's one of the most powerful features of Prisma since searching by relations is a must if you have complex data.

For something like finding the user by address, a Prisma query is as simple is:

const user = await prisma.user.findUnique({
  where: {
    address: req.query.address as string
  }
})

Smart contracts

We developed a cascade of smart contracts:

Token:

Customized ERC20 token with specific minting logic (used for vesting, exchange listings, and liquidity distribution, according to the project’s whitepaper) and Ownable feature.

Public Sale:

Original contract with whitelist providing users the opportunity to buy a preset supply of tokens at preset prices. Users were divided into two groups based on their presence in the whitelist, which was implemented on-chain using Merke Tree.

NFT holders’ claim:

The original smart contract implements the logic for NFT holders to be able to claim their NFTs and receive tokens. It was connected to the two already existing NFT collections and distributed tokens depending on NFT item rarity.

Staking:

Gives token and NFT holders an opportunity to stake (lock assets for a set period of time) their tokens and NFTs in 3 ways:

bare tokens stake - people just stake tokens and receive rewards based on their amount
single NFT stake - users can stake tokens together with an NFT item from a single collection and receive increased rewards based on the rarity of their tokens
pair NFT staking - holders can stake their tokens together with paired NFT items from different collections and receive raised rewards based on the degree of how their NFT items’ match each other and their own rarity

Vesting:

Original contract storing minted tokens and insuring them being distributed at specific timestamps and only to the prespecified contracts. Controls the token distribution and makes it transparent.

Smart Contracts were written in Solidity using OpenZeppelin libraries and were deployed, verified and tested both on testnet and mainnet using Truffle Framework. Both unit and integration tests were written in Typescript and Javascript.

That's it, let us know if you have any questions or suggestion for how we could improve the architecture.
Need web3 help? Feel free to contact us at our website or book a call.

Crafting the perfect token launchpad

Mikhail Kedzel — Thu, 27 Jul 2023 09:44:42 +0000

Our client
Project description
The result

Our client

A startup wanting to launch a token came to us, after not having any success with the last technical team. The go-to-market date was close, so we had to fit tight deadlines, while still adhering to our strict standards.

Project description 💻

We had almost no time, but still had to build a scalable, blazing-fast and secure token launchpad. We picked the perfect toolset to allow for fast but error-free development like TypeScript - a typed language for web development and Solidity - the industry standard for writing smart contracts on Ethereum blockchain. To save the client money we also leveraged Serverless - a cloud computing concept when you only pay for the number of invocations, not the server runtime. Since most of our users were in Korea, using Serverless helped us save about 80% on backend infrastructure costs.

From day one we've been able to churn out features fast thanks to our world-class developers and smart technology choices. This allowed us to build a fault-tolerant and a cost-effiecient app. We wisely chosen our deployment provider - Vercel, a leading cloud provider which built in analytics and speed insights. Which allowed us to monitor our website and backend performance in close to real time.

Frontend analytics

Frontend speed insights

Due to our extensive expertise with auditing smart contracts, we wrote truly secure Solidity code, which was approved by Certik - leading security-focused ranking platform to analyze and monitor blockchain projects.

During the public sale, our team worked round the clock to answer any questions users might have and fix urgent bugs. Thankfully, during launch no bugs were identified by users, so we can call it a success 💯

The result 🤝

We've enabled our clients to launch the perfect launchpad and hit all the targets. Continuing to work in close colloboration with the client, now we're developing a NFT marketplace toghether!

Need web3 help? Reach out to us!

Stay in Tact with TON

Mikhail Kedzel — Wed, 26 Jul 2023 07:21:20 +0000

FunC development is not fun at all!!
Tact - the savior of all FunC developers
Awesome tools for Tact development
Getting to the code
Special thanks

This article is a script of a talk we gave at TON Korea meetup telling the community about the newest tools for development on TON

First, what's so special about TON compared to other blockchains? There are a couple of cool features:

Easy integration with Telegram
Everything on-chain is a smart contract(even accounts and wallets)
Calls between contracts are asynchronous
Contract sharding is the main consensus

These provides infinite scaling, predictable gas prices and cheap execution. But my personal favorite is that there is no need for a proxy, you can make your contracts mutable to fix mistakes and easily update them. However, there's on big problem with TON.

FunC development is not fun at all!!

FunC is a very low-level language: you need to deal with TL-B schemas, TVM opcodes, and lots of hashing algorithms and ideally understand all of them. Furthermore, it has its own variable types: Cells and slices with which you have to deal regularly. Then it has the authentic syntax: functions and methods declaration vary significantly from the ones we are used to see, there are lots of syntax sugars. And my personal pain is the fact that there is only one method to deal with all the incoming messages.

That makes contracts very messy. All this sets a very high entry threshold for devs. But recently a way to loosen the burden appeared.

Tact - the savior of all FunC developers

A team of devs from TonWhales, Tonkeeper and Ton core teams created a new programming language: Tact. The first version was released in March and is regularly updated. TACT is expected to become the main language for TON smart contract development The main features are these:

it introduces Object-oriented programming elements giving the opportunity to recycle code structures
resembles Kotlin, Rust, Typescript, and Solidity in a way
has built-in methods like initializer
you don't have to deal with cells and slices
has ABI support, so you don’t need to use the client to access smart contracts

TACT is all about real necessities for devs

Awesome tools for Tact development

I use it toghether with the blueprint framework, which provides easy creation, compilation, and deployment for smart contracts. The blueprint framework has a testing suite - Sandbox, which makes testing comfortable and smooth. Another cool tool is Ton connect which supports wallets like Tonkeeper, OpenMask, TonHub, etc., and makes payment processing a piece of cake.

Getting to the code

We also recorded a video walkthrough of the code

To quickly get started let's use the blueprint framework, it'll scaffold the project with npm.
npm create ton@latest
After this command it'll prompt you to specify your project name, first contract name, and a template - choose "An empty contract (TACT)" here.

In the project directory, under contracts/imports is our first smart contract - balance.tact. Let's write some code now

import "@stdlib/deploy";
import "@stdlib/ownable";

message Withdraw{
    amount : Int as coins;
}

contract Balance with Deployable, Ownable {

    balance: Int as uint256 = 0;
    owner: Address;

    init() {
        // sender() is a built-in function which reads the sender of the message
        self.owner = sender();
    }

    // Deposit TON to our smart contract
    receive("Deposit"){
        // context() returns data of the incoming message: sender, value, type(bounced, not bounced) and its raw representation
        self.balance = self.balance + context().value;
    }

    receive(msg: Withdraw){
        // A built-in method to check that the message is sent by the owner of the contract
        self.requireOwner();
        require(msg.amount < self.balance , "Too much!");
        self.balance = self.balance - msg.amount;
        send(SendParameters{
            to: sender(),
            value: msg.amount,
            mode: SendIgnoreErrors,
            body: "Get your tokens!".asComment()
        });
    }

    get fun balance(): Int{
        return self.balance;
    }
}

Build your smart contract with this command npx blueprint build.

You should see a couple of files appear under build/Balance directory. The most interesting being the compiled FunC code - tact_Balance.code.fc.

Looking at it further, you might noticed that it's not that Gas efficient. In other words, if you were to write the same thing in FunC you'd probably save 20% on gas costs, but because Gas is so cheap on TON, it's not an issue.

Also, Tact plans to compile code straight to fift - an exteremely low-level langauge for the TON Virtual Machine and TON Blockchain. This might lead to Tact being on par, if not more gas-efficient than FunC. Exciting times are ahead for Tact

Special thanks

Thanks to the lead Blockchain Developer at MiKi Digital - Vladislav Lenskiy for preparing this awesome talk.
Thanks to Lucy Kang for hosting the event, and helping drive the adoption of TON in Korea.
And a very warm thank you to the team behind Tact language - Steve Korshakov, Tal Kol, Oleg Andreev, Kirill Emelyanenko, Kirill Maev, and others from Tonkeeper, TON Whales, TON core, etc.

P.S. If you need any web3 help feel free to reach out to us at at our website or book a call

Working with smart contract on the Frontend

Mikhail Kedzel — Tue, 04 Jul 2023 09:00:00 +0000

Working with smart conrtacts on the Frontend
Connecting to a wallet
Better UX for mobile users
Connecting to the smart contract
Exporting all the logic into a hook
Caveats
Thank you for reading

Working with smart conrtacts on the Frontend

Hello fellow web3 enthusiasts, in this article, we'll explore how to integrate smart contracts on the frontend using ethers a library for interacting with Ethereum and its ecosystem. Its often used to connect your decentralized app(dapp) to MetaMask wallet, and interact with Smart Contracts on Ethereum blockchain.

Connecting to a wallet

ethers provides an extremely simple API to connect to a wallet

if (window.ethereum) {
  const accounts = await window.ethereum.request({
    method: "eth_requestAccounts",
  });
  const account = accounts[0];

  setIsWalletConnected(true);
  setCurrentAccount(account);

  console.log("Connected Wallet:", account);
} else {
  alert("Connect your Ethereum Wallet");
}

If you are using TypeScript you'll get an error that property ethereum doesn't exist on window. To fix it create a react-app-env.d.ts in your root directory and paste the following

*/* <reference types="react-scripts" />

interface Window {
    ethereum: any
}

The only caveat is that it won't work on mobile browsers, since there's no way to install the Metamask extension on there. You'll need to use the browser inside metamask app on mobile.

Better UX for mobile users

Some mobile users might be confused if they'll open your open outside metamask. Thankfully, MetaMask has a deeplink generator which you can use to redirect mobile users to the app. Before the user open a page which requires MetaMask, you can check whether he's on mobile and redirect him if needed

<a href={\`${
        !window.ethereum ? `https://metamask.app.link/dapp/${process.env.NEXT_PUBLIC_APP_URL}\` : ''
}pagesWith/metamask\`}>Go to page</a>

Connecting to the smart contract

You'll need your smart contract's ABI stored somewhere on the FE, along with the contract address and the amount you want to send.

import { BrowserProvider, Contract, parseEther } from 'ethers';

const provider = new BrowserProvider(window.ethereum);
const signer = await provider.getSigner();
const smartContract = new Contract(
  contractAddress,
  contractABI,
  signer
);

if (isWalletConnected) {
  const valueToSend = parseEther(amount); */ Value to send in Ether
  const methodName = 'publicSale'; /* Replace with your payable method name

  const transaction = await smartContract.connect(signer)[methodName]({
  value: valueToSend
});

  const receipt = await transaction.wait();
  console.log('Transaction hash:', transaction.hash);
  console.log(receipt);
  return transaction;
} else {
  alert("Connect your wallet first to request PAC tokens.");
}

The code also checks if your wallet is connected first, before making the transaction. One of the cool features is ethers picks up the chain you are using automatically, so there's no need for additional config.

Exporting all the logic into a hook

Now, let's make our code a bit more suitable for React. All those separate functions are great, but using them in a React component can be a hassle. So let's encalpsulate everything into a hook.

import {
    useEffect,
    useState
} from "react";
import {
    abi
} from '@/mock/abi';
import {
    BrowserProvider,
    Contract,
    parseEther
} from 'ethers';

export default function useMetamaskSdk() {
    const [isWalletConnected, setIsWalletConnected] = useState(false);
    const [currentAccount, setCurrentAccount] = useState(null);

    const contractAddress: string = process.env.NEXT_PUBLIC_CONTRACT_ADDRESS // It 's better to store sensetive data like that in .env
    const contractABI = abi.abi; // Your abi, make sure to point to the Abi object itself.

    const checkIfWalletIsConnected = async () => {
        try {
            if (window.ethereum) {
                const accounts = await window.ethereum.request({
                    method: "eth<sub>requestAccounts</sub>",
                });
                const account = accounts[0];

                setIsWalletConnected(true);
                setCurrentAccount(account);

                console.log("Connected Wallet:", account);
            } else {
                alert("Connect your Ethereum Wallet");
            }
        } catch (error) {
            console.log(error);
        }
    };

    // Amount - Ether value e.g 0.003
    const requestToken = async (amount: string) => {
        try {
            const provider = new BrowserProvider(window.ethereum);
            const signer = await provider.getSigner();
            const smartContract = new Contract(
                contractAddress,
                contractABI,
                signer
            );

            if (isWalletConnected) {
                const valueToSend = parseEther(amount);*/
                Value to send in Ether
                const methodName = 'publicSale'; // Replace with your payable method name

                const transaction = await smartContract.connect(signer).[methodName]({
                    value: valueToSend
                });

                const receipt = await transaction.wait();
                console.log('Transaction hash:', transaction.hash);
                console.log(receipt);
                return transaction;
            } else {
                alert("Connect your wallet first to request PAC tokens.");
            }
        } catch (error) {
            console.log(error);
        }
    };

    // Connecting the wallet on the first render
    useEffect(() => {
        checkIfWalletIsConnected();
    }, []);

    return {
        requestToken,
        checkIfWalletIsConnected,
        isWalletConnected,
        currentAccount
    }
}

Caveats

There's a couple of downsides to using ethers instead of Moralis

Mobile experience suffers a bit, since users have to go through MetaMask browser instead of their preferred one. With Moralis, you can use WalletConnect which recently started supporting MetaMask, so you can do it all in your browser.
Poor wallet support. When using WalletConnect instead of ethers, you have a much wider choice of wallets. Even thought MetaMask is used by 80-90% of users, you can grow your user base by offering more wallet options.

Moralis isn't the silver bullet as well, since compared to ethers its API isn't that powerful. So you need to weigh the upsides and downsides of both. We'll cover using Moralis in our next article, so you could compare it with ethers and decide easily.

Thank you for reading

If you have any questions or suggestions, feel free to leave them in the comments!

At MiKi we help businesses make stunning websites with a blazing-fast and cost-efficient cloud backend.
Interested?
Feel free to give us a call at +447588739366, book a meeting at https://lnkd.in/gGmfJu8z or feel out the contact form at our website https://www.miki.digital/contact

4 Lessons learned from using NextJS 13 in production

Mikhail Kedzel — Thu, 29 Jun 2023 16:33:08 +0000

We’ve recently rebuilt our website with NextJS V13 app directory, and what a journey it was! As app directory is(at the time of writing this article) in beta, it wasn’t all smooth sailing, but once we got the hang of it - our website speed improved by quite a lot. To help other developers starting with NextJS 13, we’ve compiled a list of 10 of the most important lessons we learned. You can use those as mental guidelines for writing performance NextJS 13 code.

Read all the available documentation before writing any code.

Often when we see a cool new feature, we want to build something with it right away, hoping to learn it in the process. If the deadlines are tight, it seems even more viable.

But NextJS 13 introduces many new concepts, which are pretty high-level, so the biggest recommendation is to read ALL of the available documentation before writing any code. And then reread this documentation as needed. Here are some of our favorite sources(in the order that we’d recommend reading them)

React documentation on Server Components(used be NextJS 13 under the hood)
Difference between SSR and React Server Components
Main takeaways of React Server Components
NextJS Docs
HackerNews(Dan Abramov answered some of the comments!)

Minimize the amount of client components

In general, less client components - more performance. Before creating a new page, we suggest making a high-level overview of what that page will look like.

For example, you want to build a simple “Contact Us” form with a react-hook-form and some Captcha library. The Captcha library's provider component requires you to write ‘use client’. The simplest way of creating that page would be

page.tsx

'use client'

function Page() {
  return (
    <CaptchaProvider>
      <SomeStaticContent/>
      <form>
        ...react-hook-form
      </form>
    </CaptchaProvider>
  )
}

Setting ‘use client’ for the whole page is a bad practice. But even if our <CaptchaProvider/> is a Client Component, you can pass a Server Component as a child or prop of a Client Component

From React docs

A Server Component may pass another Server Component as a child to a Client Component: <ClientTabBar><ServerTabContent /></ClientTabBar>. From the Client Component’s perspective, its child will be an already rendered tree, such as the ServerTabContent output. This means that Server and Client components can be nested and interleaved in the tree at any level.

This means only <CaptchaProvider/> needs to be a Client component. As per NextJS docs, we can wrap our provider in our own client component

customCaptchaProvider.tsx

'use client'

import { CaptchaProvider } from 'captcha-library'

export default CaptchaProvider

Now we can remove the ‘use client’ from page.tsx

page.tsx

import OurCaptchaProvider from './customCaptchaProvider'

function Page() {
  return (
    <OurCaptchaProvider>
      <SomeStaticContent/>
      <form>
        ...react-hook-form
      </form>
    </OurCaptchaProvider>
  )
}

But, react-hook-form relies on useRef under the hood, which can’t be used in a Server Component. We can extract the form into a separate client component

ContactUsForm.tsx

'use client'

function ContactUs() {
  return (
    <form>
      ...react-hook-form
    </form>
  )
}

page.tsx

import OurCaptchaProvider from './CustomCaptchaProvider'
import ContactUs from './ContactUsForm'

function Page() {
  return (
    <OurCaptchaProvider>
      <SomeStaticContent/>
      <ContactUs/>
    </OurCaptchaProvider>
  )
}

If <SomeStaticContent> is a small component, the difference won’t be that big, but the larger it gets, the more noticeable the difference will become. As a rule of thumb, you should try to make every component a Server Component first and resort to Client Components if you can’t.

Get comfortable with SWR or React Query for fetching on the client

Client components don’t support fetch() yet, so you’ll have to use either SWR or React Query for fetching data in Client Components. If you aren’t very familiar with those libraries, we’d recommend trying them out in a regular React project first to get comfortable with the fundamentals and choose the library that works for you. For MiKi website, we went with SWR, and it was a pretty smooth experience, so this might be a good starting point.

In Server Components, you can use fetch() without any issues since Server Components support async/await right inside the component. As a general rule, NextJS recommends fetching data in Server Components as much as possible.

Change your “stance” against npm packages

Using npm packages greatly improves the development speed. But remember the time when before installing some library, you had to check https://bundlephobia.com/ to see how it would affect bundle size and page load time? So many developers became against the excessive use of npm packages, as it can make your bundle size bigger, leading to slower compile and load times.

Since Server Components are run only on the server, they don’t impact bundle size. With this in mind, you should be more open to using npm packages - this will save time and bring us to a more modular future where the functionality you need to be may already exist in npm. Even if the library weighs a lot, you can use it in Server Components without negatively affecting the bundle size.

However, you have to remember that this is only true for Server Components, using a big library in a Client Component will still negatively affect your bundle size. As we advised earlier - try to make as few Client Components as possible.

Thank you for reading

Those were the four most important tips we wanted to share. Hope they’ll make you a better NextJS 13 developer. If you have any questions or suggestions, feel free to leave them in the comments.

Creating a useState hook from scratch

Mikhail Kedzel — Thu, 22 Jun 2023 12:00:00 +0000

In this article, we’ll create the most barebones version of the useState hook. If you want to understand how React hooks work in depth, how they use closures, and why can’t you nest hooks in if blocks - read ahead!

First of all, you probably know that React doesn’t need JSX, and in the end, it transforms everything to React.createElement(component, props, ...children) . You can read more about it in the official docs https://reactjs.org/docs/react-without-jsx.html

With this in mind, to not overcomplicate ourselves, let’s create just a .ts file called index.ts. Then, we can add our simple custom component without any JSX.



function App() {
  const [count, setCount] = useState(0);

  return {
    count: `Count is ${count}`,
    setCount
  };
}

To emulate rendering and re-rendering, we’ll do the same thing that React does - just call the function. Then we’ll get our count and log it to see what’s there.



function App() {
  const [count, setCount] = useState(0);

  return {
    count: `Count is ${count}`,
    setCount
  };
}

const Rendered = App();
console.log(Rendered.count);

Oh, right, useState is not defined… Let’s create it!

We need our function to accept initialState and return an array of two items - state and a function to modify it.



function useState(initialState?: any) {
  let state = initialState ?? undefined;

  return [state, (newState: any) => (state = newState)];
}

Let’s run our code again

We’re getting somewhere :). But let’s try to change our state



let Rendered = App();
console.log(Rendered.count);
Rendered.setCount(10);
Rendered = App() //re-render after state change
console.log(Rendered.count);

Same thing. That’s because our useState function gets re-created on every re-render

We can use closures to our advantage here and lift the state up to be a global variable not to get re-created on every re-render.



let state: any;

function useState(initialState?: any) {
  /* We want to check if state is undefined, i.e. it's the first render
     before assigning initialState to it.
  */
  if(typeof state === 'undefined') state = initialState;

  return [state, (newState: any) => (state = newState)];
}

Much better, but how do we go about creating two states? Three states?



function App() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState("John");

  return {
    count: `Count is ${count}`,
    setCount,
    name: `Name is ${name}`,
    setName
  };
}

let Rendered = App();
console.log(Rendered.count);
console.log(Rendered.name);
Rendered.setCount(10);
Rendered.setName("Mark");
Rendered = App(); //re-render after state change
console.log(Rendered.count);
console.log(Rendered.name);

Since we only have one global state variable, our two useStates have to share it, which leads to incorrect behavior.

The way React implements it - is by having a state array and a pointer to know which useState we are currently on. After the useState function is fired, it increments this pointer so that the next useState function will work with its state, and so on. After a re-render, since our App() and all the useState functions are called again, we need to set this pointer to 0. Can you already guess why nesting a useState in an if statement is bad?



let state: any[] = [];
let index = 0;

function useState(initialState?: any) {
  // Freeze the index, to make the 'setters'(setCount/setName) work
  const localIndex = index;
  if (typeof state[localIndex] === 'undefined') state[localIndex] = initialState;

  index++;
  return [state[localIndex], (newState: any) => (state[localIndex] = newState)];
}

function App() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState("John");

  return {
    count: `Count is ${count}`,
    setCount,
    name: `Name is ${name}`,
    setName
  };
}

let Rendered = App();
console.log(Rendered.count);
console.log(Rendered.name);
Rendered.setCount(10);
Rendered.setName("Mark");
index = 0; //Set the index to 0
Rendered = App(); //re-render after state change
console.log(Rendered.count);
console.log(Rendered.name);

One more trick we are doing here is “freezing” the index. Otherwise, when we get to the “name” useState, it’ll increment the index to 1, and setCount will end up changing the name instead of count. Because name has an index of 1 and count has an index of 0

Let’s see where it got us!

Works perfectly!

Conclusion

Of course, having built this we are still far of from becoming a React maintainer at Facebook :) But the best way to learn something is by doing it. So here are a couple of ways you can improve this on your own

Instead of manually setting index to 0 before calling our function every time, encapsulate this into a render method which’d do both.
Store your custom React in an IIFE instead of globally in our index.ts file, just like React does it https://developer.mozilla.org/en-US/docs/Glossary/IIFE
Implement useEffect
Use your imagination and implement more stuff!

This article was inspired by two great talks:

https://www.youtube.com/watch?v=KJP1E-Y-xyo

https://www.youtube.com/watch?v=f2mMOiCSj5c

Thank you for reading!

At MiKi(https://miki.digital/) we help businesses make stunning websites with a blazing-fast and cost-efficient cloud backend.
Interested?
Feel free to give us a call at +447588739366, book a meeting at https://calendly.com/miki-digital/30-minute-consultation or feel out the contact form at our website https://www.miki.digital/contact

Reducing Lambda bundle size with EsBuild and Lambda layers

Mikhail Kedzel — Fri, 16 Jun 2023 12:43:42 +0000

Serverless is becoming increasingly popular as it lifts the burden of having to manage your servers and is more economical than cloud containers or on-premise servers. Popular BE frameworks like NestJS allow you to switch from containerized to lambda quite easily. https://docs.nestjs.com/faq/serverless

While by just transforming your monolithic backend into one lambda, you’d already see the benefits like easier management, less cost, and, maybe, improved performance. But the performance aspect is the most difficult, as having one “fat” lambda with a huge bundle size will lead to slow cold start times. Since during cold starts, Lambda downloads all your code, and the bigger your bundle is - the longer it’ll take to download.

In this article, we’ll explore the approaches we use at MiKi to optimize that using Lambda layers, EsBuild, and smarter BE framework choices.

Choosing the right framework

First, let’s see how much overhead a modern fully-fledged framework adds. Let’s say we want to build an AppSync Api with a lambda behind it, along with some basic authorization.

I’ve left out quite a few dependencies; only included the core ones, to make the comparison easier.

But do we need all those dependencies, or can we write something from scratch using mostly what NodeJS gives us? Instead of NestJS’s dependency injection, we can use tools like tsyringe or typedi, etc. We can recreate the graphql annotations that NestJS gives us with type-graphql. And like in the NestJS example, we’ll also need graphql and typeorm.

I’ve left out quite a few dependencies; only included the core ones, to make the comparison easier.

Already, it’s three times smaller than before, but we can do better

Splitting into multiple smaller lambdas

We’ll need to do some re-architecting to decouple our code and make many small, independent lambdas. This will reduce the bundle size even further, since every lambda will only import the dependencies it needs. For example, auth dependencies can only be imported by your auth lambda. Or, if you have a number of big libraries for some specific functionality, you can extract this into a separate lambda, to reduce the bundle size of other lambdas.

Note that I’m not talking about microservice architecture here because all our lambdas can still use the same database.

Making our bundling speed extremely fast

NestJS uses webpack under the hood, which might be one of the slowest bundlers. Since we got rid of NestJS, we can choose a more performant bundler. One of the best options is esbuild - “An extremely fast bundler for the web” (c).

Faster bundling will improve the performance of your CI/CD by 10-100x allowing your developers to work more productively.

Using Lambda layers

Our final step on the way to the tiniest bundle you’ve ever seen is to leverage Lambda layers. It allows you to move your common dependencies to a “layer”, then every lambda would only bundle its unique dependencies, accessing everything else from the layer. A layer is just a zip file, where we can put our node_modules and package.json . Or, we can put only the package.json and create a step in our CI/CD pipeline that would install the dependencies.

Due to the way node_modules resolution works

Node.js starts at the directory of the current module, adds /node_modules, and attempts to load the module from that location.

If our lambda will not find a dependency in local node_modules, it’ll go one level up and search in our layer. Let’s adjust our esbuild config to only bundle the unique dependencies.



const { build } = require('esbuild');

// Needed to make decorators work

const { esbuildDecorators } = require('@anatine/esbuild-decorators');

const pkg = require('./layer/nodejs/package.json');

const fs = require('fs');

const path = require('path');

const externals = [

  ...Object.keys(pkg.dependencies || {}),

  ...Object.keys(pkg.peerDependencies || {}),

];

function getEndpoints() {

  const lambdasFolder = path.join(__dirname, './src/lambdas');

  const files = fs.readdirSync(lambdasFolder);

  return files

    .filter((file) => file.endsWith('.ts'))

    .map((file) => path.join(lambdasFolder, file));

}

async function bundle() {

  const tsconfig = path.join(dirname, './tsconfig.json');

  return build({

    platform: 'node',

    target: 'node14',

    bundle: true,

    sourcemap: false,

    plugins: [await esbuildDecorators({ tsconfig })],

    entryPoints: getEndpoints(),

    outdir: path.join(dirname, 'dist'),

    tsconfig,

    format: 'cjs',

    treeShaking: true,

    external: externals,

  }).then((value) => {

    // eslint-disable-next-line no-console

    console.log('Build completed: ', value);

  });

}

bundle().catch((err) => {

  // eslint-disable-next-line no-console

  console.error(err.message);

  process.exit(1);

});

Conclusion

I went through the same transformation in an averagely-sized commercial project, and, compared to one fat lambda, the bundle size of each of our small lambdas was on average 20 times smaller. So next time you build a project from scratch, or will want to improve the performance of an existing application, I advise you to re-evaluate the need for a fully-fledged BE framework. Since most of the time, a more minimalist approach will give you way better performance and, consequently, lesser costs.

Atomic design

Mikhail Kedzel — Tue, 06 Jun 2023 12:21:01 +0000

At the dawn of web development, we used to have extremely simple pages, with most of the logic being on the backend. But nowadays, having a thoughtfully designed and built website is crucial to success, as among all factors for rejecting/mistrusting a website, over 94% are related to poor design. So better-looking websites help to build trust with your customers and attract more people.

With the advance of development, we also started to value the separation of concerns and modularity more. So it became clear that we needed to create functionality in a reusable way. On the FE, this can be achieved with a design system.

In short, the UI/UX designer creates simple, building-blocks components like inputs, alerts, buttons, etc., and then starts building pages using as many existing components as possible. The developer can also create the basic components and then build the pages like lego using the pieces(components) they already have. A good design system can be a game changer - allowing your designers and developers to create and iterate faster.

“Atomic design” is an amazing design system that takes its inspiration from chemistry. Like in web design, everything can be built from simple components like inputs, text, buttons; in chemistry, everything is built from atoms. In Atomic design, there are five levels of components.

Atoms - basic building blocks like buttons, text, inputs
Molecules - more complex components combining multiple atoms, e.g. a search input - combines input, label text, and a button
Organisms - rather complex components made from molecules like headers or footers
Templates - A page made from organisms but without any real content. In terms of React, this can be a layout component.
Pages - A specific instance of a template, a real page in your application

The distinction between templates and pages is rather hard to see, especially in frameworks like React, where a page is just a “template” because some content can be dynamic, i.e., fetched from the server.

Atomic design provides you with a clear mental model of separating components and creating design systems. It makes you write more reusable code by encouraging you to use more components and make your code more modular. It can greatly speed up work because after the initial investment in building out reusable components, creating actual pages will be much easier.

Have you tried Atomic design?

When should you leverage no-code or low-code

Mikhail Kedzel — Thu, 20 Apr 2023 06:34:04 +0000

When starting on a new website, even before selecting a framework or a JavaScript library, you should first decide if you want to write code. Perhaps, 10 or more years ago, this wasn't even a question, but now there are so many extremely powerful yet easy-to-use no-code and low-code solutions. More and more companies are tapping into the potential of low-code to save them time and money. Low-code seems like the perfect solution for an early-stage startup or someone who wants to build out a test version of their website.

So, should you delete all your JavaScript apps and immediately switch to low-code? Well, it's not that one-sided. In my experience, almost every startup I've helped leveraged a no-code solution when they had just started, but practically no one ended up going with it all the way through. Since, with low-code, it can be impossible to customize your website beyond what the low-code platform allows you, and often the customization can be limited. So when and why using a modern JavaScript framework instead of a low-code platform can be a better choice?

You want to have more control over your website

Even if you are building out a small website, no-code, and low-code platforms provide a pretty high level of abstraction. Sometimes, it's good enough, but you'd often want to customize SEO, install a custom library or a design framework. Those all can be impossible since low-code platforms provide you with a pre-defined set of tools.
Using a modern JS framework like React or NextJS can make your website faster than a no-code platform because you can leverage the newest tools and library versions. For example, NextJS 13 supports React Server Components, making your app much faster. Want to use it? Well, a low-code platform probably doesn't support it.

Avoid vendor lock-in

If you've built out your app on one low-code platform, transferring it to another may be cumbersome. But, for example, if you use React, you can deploy your app anywhere you want. If you deployed your frontend on AWS Amplify and it stops working one day, you can always deploy on Firebase or Vercel instead. Of course, you'll have to change your CI/CD, but it's still easier than changing a low-code platform, in my experience.

More longevity

On the one hand, it can be easy to innovate with a low-code solution, since you spend less time writing code and more time creating business features. So, you can iterate faster and try out new ideas without investing much time.
On the other hand, the no-code and low-code world innovates even faster than the JavaScript world. React has been around for many years, and you can expect it to be actively maintained for the foreseeable future. There are many more low-code development websites than JS frameworks, so many can be less maintained and have less longevity.

Conclusion

There is no one size fits all approach when it comes to going with low-code or not. It all comes down to personal preference, and mostly the deadlines and the budget. Need to get a good-looking website quickly and for a low development cost - use low or even no-code solutions. Want to invest more time and build a more future-proof and customizable app - build it from scratch with a modern JS framework.

DEV Community: Mikhail Kedzel

Creating a blockchain based digital passport

Our client

Project description

The result

How to build the largest web3 community in Korea

How to build the largest web3 community in Korea

Getting into crypto

Starting SojuDAO

Changing Social Networking in Web3

Overall thoughts on web3

Crafting the perfect token launchpad - technical description

Frontend

Blockchain integration library

Doing it the React way

Backend

Connecting to the database

Smart contracts

Token:

Public Sale:

NFT holders’ claim:

Staking:

Vesting:

Crafting the perfect token launchpad

Table of contents

Our client

Project description 💻

The result 🤝

Stay in Tact with TON

Table of Contents

FunC development is not fun at all!!

Tact - the savior of all FunC developers

Awesome tools for Tact development

Getting to the code

Special thanks

Working with smart contract on the Frontend

Table of Contents

Working with smart conrtacts on the Frontend

Connecting to a wallet

Better UX for mobile users

Connecting to the smart contract

Exporting all the logic into a hook

Caveats

Thank you for reading

4 Lessons learned from using NextJS 13 in production

Read all the available documentation before writing any code.

Minimize the amount of client components

Get comfortable with SWR or React Query for fetching on the client

Change your “stance” against npm packages

Thank you for reading

Creating a useState hook from scratch

Conclusion

Reducing Lambda bundle size with EsBuild and Lambda layers

Choosing the right framework

Splitting into multiple smaller lambdas

Making our bundling speed extremely fast

Using Lambda layers

Conclusion

Atomic design

When should you leverage no-code or low-code

You want to have more control over your website

Avoid vendor lock-in

More longevity

Conclusion