Spocket

spocket

Shopify is the most-loved platform for b2b businesses and e-commerce enthusiasts. Almost 1.8 million stores run on Shopify. If you want to sell products in bulk or at wholesale prices on your Shopify store, there are over 260+ apps available in the Shopify app store that can help you with it. Some are good, some are a total waste. This blog post will cover the top 7 Shopify wholesale apps with their features and pricing. These apps are useful to display wholesale signup forms, products catalog,  order forms, discounted prices, volume/tiered discounts, minimum order quantity, coupons, custom shipping rates, and more. Some of these apps will help you control the visitor access to your Shopify store by hiding prices, products, or password-protect specific pages. Shopify has its own app called Wholesale that let’s you customize your store for wholesale/b2b experience - but it is . Note: only available to the users Shopify Plus The best Shopify wholesale apps in 2022: Wholesale Pricing Discount Wholesale Club Wholesale Lock Manager Inkybay - Product Personalizer Wholesale Order Form Spocket - US & EU Dropshipping Charge Me Later, Wholesale app 1. Wholesale Pricing Discount $19.99 - $44.99 per month (21-day free trial available) Price: Wholesale Pricing Discount (WPD) is arguably the best wholesale app out there for Shopify online stores. It offers a simple UI that allows you to create a Dedicated Wholesale Section that you can add to your store’s navigation or you also have an option to run a combined B2C/B2B wholesale store on your existing store. The WPD app offers almost everything you need to set up a wholesale program. You get to set volume/tiered pricing, individual variant pricing, shipping rates, discounts based on minimum order quantity & item weight, net terms, percentage/price discounts, coupons, wholesale signup form and much more. The Wholesale Pricing Discount app is available for a 21-day free trial. The features offered are based on the three pricing plan options basic, professional and enterprise. 2. Wholesale Club $29 - $59 per month (30-day free trial available) Price: Wholesale Club is another good wholesale app for Shopify that offers you some great basic features to run your B2B ecommerce business at ease. The Wholesale Club app has many amazing features such as custom prices, order minimums, volume discounts, net payment terms and quick order form. The Wholesale Club app is available for a 30-day free trial with an overall 4.7 user rating. The number of features offered in this app is based on the two pricing plan options basic & professional. 3. Wholesale Lock Manager $6.99 per month (8-day free trial available) Price: Wholesale Lock Manager is the perfect app for you if you want to hide product prices or the entire product page on your Shopify store. This app offers you simple locks that let you control visitor access to your store. For example, if you’re running a wholesale or a B2B program where you want only your B2B customers to visit specific products then you can configure or create a lock accordingly in the app with a few simple steps. There are many great features offered by the Wholesale Lock Manager app such as password-protect pages, sharing secret links, login to view prices, hiding prices, hiding products & collections, and much more. The Wholesale Lock Manager app is available for an 8-day free trial. There is a good alternative to this app such as the Locksmith app but it costs a bit higher and offers almost similar features. 4. Inkybay - Product Personalizer $19.99 - $249.99 per month (21-day free trial available) Price: Inkybay - Product Personalizer is a Shopify app that lets you customize your product pages and it also offers you some features to sell your products at tiered discounts. The key features of the Inkybay app include product configuration & designing, tiered pricing, custom order, a quantity discount, and much more. Inkybay app is available for a 21-day free trial. This is the app for store owners who want very minimal features of customizations for displaying tiered discounts on their product pages but want to do more customizations to the design of the product pages. 5. Wholesale Order Form & ReOrder $12.99 - $24.99 per month (8-day free trial available) Price: Wholesale Order Form & ReOrder app is a great option if you want to take bulk orders from your customers on Shopify. This app offers a single-page order form that allows your customers to quickly add multiple products directly to their cart in one place. You can generate an order form for your store with just a single click and add it to your store’s navigation. This app also offers a reorder feature where logged-in customers can simply edit and reorder from their previously placed orders on your store. The Wholesale Order Form & ReOrder app is available for an 8-day free trial and is highlighted as Seamless workflow, Up-to-date tech, and Speed tested in the Shopify app store. 6. Spocket - US & EU Dropshipping Free - $99.99 per month (21-day free trial available) Price: Spocket is a Shopify app that gives you access to high-quality products from US and EU suppliers. You can either choose to dropship these products or order them in bulk at wholesale prices. Sprocket app also offers discounts on shipping rates and exclusive deals on product pricing, which can help you save money and grow your business. https://youtu.be/f6P8K26OMzI Spocket has a free plan as well as paid plans starting at $24.99//month. 7. Charge Me Later, Wholesale app $9.99 - $29.99 per month (4-day free trial available) Price: Charge Me Later is a Shopify app that allows you to offer financing options to your wholesale customers. You can configure their Pay Later feature for your products and you can also manage your wholesale pricing and quantity discounts. Charge Me Later has a 4-day free trial and paid plans starting at $9.99/month. The number of features offered in this app is based on the three pricing plan options basic, plus & gold. There you have it! These are the best Shopify wholesale apps for 2022 that will help you and grow your B2B revenue in no time. increase sales Do you have any other Shopify wholesale apps that you love? Let me know in the comments below :) This story was submitted to HackerNoon by an independent contributor. Hence the information contained therein has also been researched and compiled independently. Disclosure:

The Best Shopify Wholesale Apps for 2022

When creating a business based around drop shipping, most of the focus can often go into what your site looks like, what you sell, which platform you’re on, etc. These are all important aspects, but something of equal importance to remember is where you are getting your products from. One of the most popular places to get products from is AliExpress. This article will explain why AliExpress isn’t always the best option, and what other options there are if you decide AliExpress isn’t for you. What is Drop shipping? When ordering products, most traditional businesses will buy in bulk, so they have all their products available as soon as their customers want them. This can lead to additional stock which hasn’t been sold - to get rid of this stock these stores will often have sales so the stock can move along to make more room in their warehouses. This is not the only way of getting products. With drop shipping, you only order what you need, which cuts out the need for sales and unnecessary storage space. Drop shipping businesses will act as a ‘middle-man’ in the buying process. A person will order a product from your business at retail price, and then the business will purchase that product from a third-party seller (such as ) at wholesale price. By using this method, you are limiting the unnecessary products you carry and are maximizing your profits by not spending too much on storage. AliExpress Is Drop shipping ethical? When discussing drop shipping, a question that routinely comes up is ‘is drop shipping ethical?’ The short answer is, yes - Drop shipping is ethical. Whenever a business is selling something there is always the potential for extortion. As long as you are charging fair prices for your wares and are not taking advantage of anyone there is no reason why your drop shipping venture would be unethical. What’s the problem with AliExpress? The vast majority of AliExpress suppliers are based in Asia. This means that if you are wanting to order some product from them it could take a long time for it to get delivered to your country or the country that the customer is in. This leaves you with the option of whether or not to wait for the long delivery times or to have some product in storage available to deliver immediately. Both options could hypothetically work, but with sites like Amazon being able to offer next-day or even same-day delivery consumers’ tolerance for wait times has gone down dramatically. Also, keeping a select amount of products at hand can be beneficial, but if you’re starting to store too much you are lessening some of the benefits of drop shipping. Namely needing less storage space for product. It is possible to find AliExpress shippers that have warehouses in the US, but this is often more difficult for a variety of reasons. There is no way for AliExpress to verify the location of a warehouse, so many lie about their location, knowing that people are more likely to buy from them if they say they’re based in the US. Additionally, since these US-based AliExpress sellers know that they are in demand they are able to have higher prices than some of the Asia-based warehouses. People are still using AliExpress to procure their stock. This is largely due to two reasons: One, AliExpress is one of the in the world, meaning that it will always be at the forefront of people’s minds when deciding what site to use. The other reason is that because of their size, AliExpress is able to offer cheaper prices on products compared to other companies. largest online retailers In short, there are reasons that people still use AliExpress to get their product, but if you are wanting to reduce the delivery times, and not spend more money unnecessarily there are alternatives available. What are the alternatives? A potential alternative to AliExpress is . HyperSKU has a number of processing centers in the US as well as having multiple others based in Europe. This will rapidly decrease the time it takes for products to get to you, usually arriving in less than half the time it would take if you were to purchase from a seller in China. You can also order a batch of inventory and send to their US warehouses to avoid the holiday season rush. Setting up a HyperSKU account is completely free, so there is minimal risk involved on that front. HyperSKU makes their money from the shipping costs and product margins in getting the goods to you, so there is no need to worry about any hidden costs. HyperSKU One of the potential downsides to HyperSKU is that their stock can be more expensive than AliExpress, so it becomes a question of whether the decreased delivery time is worth paying more for the product. Another alternative to AliExpress for getting your products is . Spocket has suppliers all across the world, so you can choose to buy from a local supplier, to avoid longer delivery times. Spocket Comparatively, Spocket has significantly fewer product options available than HyperSKU, so you may not be able to get everything you want to sell from them. Conclusion There are positives and negatives to every platform that you can get products from. If there was a clear better option, then no other ones would exist. In the end, it comes down to a personal preference - what’s more important to your business. If you value your time the most and want to reduce your delivery times then I would suggest working with HyperSKU. They offer a large array of products and are able to get them to you faster than a lot of other dropship suppliers. However, if you are just starting out and need the prices to be as low as possible, then it may be worth staying with AliExpress for a while whilst you find your footing in the market.

Drop Shipping Alternatives to AliExpress in the US

Most crypto traders are comparing 2020 with 2017 when Bitcoin hit its all-time-high of $20,000 and altcoins were doing a 2-5-10x in just a matter of days. This year is different, though. Traders, holders, and investors have more knowledge and the market growth is not based on hype. The crypto market is close to reaching mainstream adoption and that wouldn’t be possible without all the DeFi (Decentralized Projects) that are making crypto more accessible and easy to use for the average user. Anyway, while I consider myself already a seasoned crypto trader, I was thinking; ‘Why am I still using the same tools as years ago?’ That’s when I dug into the latest DeFi tools and I discovered a whole new world that not only that saves me hours of my day, but it saves me up to 50% in transaction fees and gives me data analytics that I didn’t know I could have access too! No matter if you are an experienced crypto trader like me, a new investor who just found out about crypto, or a long time holder, the tools I’m about to introduce to you will definitely improve your experience with cryptocurrency. But, first, let’s understand how these tools are different than the ones you’re used to. Why decentralized tools? DeFi means blockchain takes control, literally. Centralized exchanges are nice but the counterparty risk is way too big, especially if you are going to stay invested in cryptocurrency as in most countries converting back to fiat is a taxable event and you might not want to fill the government:s pocket more than you need to. DEXs (Decentralized Exchanges) were the first tools that allowed you to trade cryptocurrency without losing control of your coins in the process. Great tools but in terms of usability, DEXs are a mess. If you ever tied one, you know that you are going to spend double or even triple the time you would normally do just to double check every address and every detail before placing an order. Not only that they were inefficient but they also lacked liquidity. Filling in an order would take days. Most likely because everyone was using a centralized exchange and wouldn’t want to make a change. And I don’t blame them; I was in the same place too. The new DeFi tools are different. They are non-custodial financial products (like DEXs) but they improved a lot on the user experience. Not only that but they are including features that weren’t accessible before in any other exchange. The tools I’ve chosen are becoming a one-stop shop for me to do all my cryptocurrency trades so I’m sure I’m not losing on any possible gains. Here are three tools you might consider using for your next trades and investment choices. Simplified Finance for trading is a decentralized finance protocol formed by two core products: GNS (Gas Reduction Token) and SMFI (Governance Token) that are designed to help you handle your trades at just a fraction of the cost you are paying at any of the other decentralized finance protocols like Uniswap, 1inch.exchange and Yearn Finance. Simplified Finance GNS gives you the benefit of hedging against the volatility of gas fees. This means that when the prices are going up and the gas prices spike, you won’t have to pay those extremely high fees. SMFI makes sure that the ecosystem remains healthy with governance and incentives. New users will be brought in through the referral protocol and buyback burn mechanism to make sure that only the most invested users will be able to vote on future protocol decisions. Simplified Finance is not an exchange although you can trade your tokens as you’d do on one. It doesn’t have an order book. It’s working on a model called Constant Asset Market Maker where reserves are provided by liquidity providers. Anyone can be a liquidity provider and every trade happens on-chain through smart contracts. Regardless if you choose to participate as a trader or a liquidity provider you are going to win: As a liquidity provider you are going to earn from the trading fees As a trader you are going to pay significantly less fees than on any other platform Other options are , and . Uniswap is the most popular right now and has a battle-tested algorithm to determine the prices. 1inch.exchange has a great API and many developers are choosing to implement it. And Yearn Finance is the new kid in town with better deals. But neither comes even close to Simplified Finance low fees. Uniswap 1inch.exchange Yearn Finance Dune Analytics for market data is a blockchain data analytics startup. As you need data to decide on what tokens to get, this tool is a global, real-time platform for on-chain data analysis. I’m talking about charts, diagrams, tables, a place where you can get and remix data in any way possible. Dune Analytics Currently, Dune is the most open and up to date platform in the crypto space. Here you can make sure that your data is synced fast as its competitors are putting restrictions in terms of what you can query. Some traders are considering Dune the default platform for getting market data and not only them. You don’t need to be tech-savvy to use it. Instead of blindly trusting a project, you can give Dune a try to verify its data on-chain for yourself beyond whatever their website or white paper claims. Let me explain a query in more simple terms so you know what you’d be facing. In your dashboard, you’ll have access to live Ethereum data like blocks, events, transactions, receipts, contract messages. You can look for a specific transaction or track a certain address, or you can choose a time range and pull up all the events of a type, all the blocks where a certain type of transaction took place or even look for ERC20 transfers. Other alternatives are , , or . Bloxy extends its analytics to margin trading positions if you are interested in that kind of data. Stablecoin Index offers dedicated analytics for stablecoins. And Uniswap.vision is a collection of community-made charts. Bloxy Stablecoin Index Uniswap.vision StablePay for cryptocurrency payments is a decentralized payment platform which helps you to make payments with ETH or any other ERC20 token. It’s an important tool as I mentioned in the beginning of the article that it’s best to keep your funds in cryptocurrency while trading. Let’s say you would want to get back into USD so you’re not exposed to other tokens volatility. There are many stablecoins backed by USD like USDT and DAI. With StablePay you can keep your funds in one of these coins and spend them with ease. StablePay The projects created an ecosystem where any ERC20 tokens gets instantly converted into a token of the receiver’s choosing. The mechanism is leveraging the liquidity of several liquidity providers to help the receiver to avoid the volatility of the crypto space during the transaction. The transferred tokens can be in any token and the process is as simple as PayPal or other email-based payment platforms. Within the app, you are getting a personalized link to request a payment via the URL. You can receive payments, donations, tips, it can be used in any possible way. Once a transaction reaches your wallet, your newly received funds will start generating interest. The whole process takes seconds! Other alternatives are and . Sablier is a platform where the funds are being streamed to a dedicated address during a determined time. Request is a platform that allows invoicing for cryptocurrency payments. But neither of them has the option for the users to earn interest on their newly received funds. Sablier Request 2020 is coming to an end but the crypto market is just getting started. There are no excuses to stay away from such opportunities when such tools are available for free to anyone willing to join!

What DeFi Tools Can You Use During this Market Cycle? - 2020 Market Research

A minority, but still a massive number of projects, require web sockets integration to provide instant reaction of an interface on changes without re-fetching data. It’s an essential thing, and we are not going to talk about them or make a comparison between 3rd-party libraries that provide API for a better dev experience. My goal is to show how to integrate quickly with NextJs. And how to solve the problems we faced during development. @microsoft/signalr I hope everyone has already installed and deployed the NextJS project locally. In my case, the version is . Let’s add some more important libraries: (version ) for data fetching and further work with the local cache and (version ) - API for web sockets. 13.2.4 swr 2.1.5 @microsoft/signalr 7.0.5 npm install --save @microsoft/signalr swr Let’s start with creating a simple function and a new hook called to get initial data from our REST API. It returns a list of the messages for the chat, fields that detect errors and loading state, and the method that allows to change cached data. fetcher useChatData mutate // hooks/useChatData.ts
import useSWR from 'swr';

type Message = {
    content: string;
    createdAt: Date;
    id: string;
};

async function fetcher<TResponse>(url: string, config: RequestInit): Promise<TResponse> {
    const response = await fetch(url, config);
    if (!response.ok) {
        throw response;
    }
    return await response.json();
}

export const useChatData = () => {
    const { data, error, isLoading, mutate } = useSWR<Message[]>('OUR_API_URL', fetcher);
    return {
        data: data || [],
        isLoading,
        isError: error,
        mutate,
    };
}; To test that it works as it is supposed, let’s update our page component. Import our hook at the top, and extract data from it like in the snippet below. If it works, you will see rendered data. As you see, it’s quite simple. // pages/chat.ts
import { useChatData } from 'hooks/useChatData';

const Chat: NextPage = () => {
	const { data } = useChatData();

	return (
		<div>
            {data.map(item => (
                <div key={item.id}>{item.content}</div>
             ))}
        </div>	
	);
}; The next step requires connecting our future page to web sockets, catching events, and updating a cache with a new message. I propose to start with building the socket service in a separate file. NewMessage According to the examples in SignalR docs, we have to create an instance of connection for further listening to events. I also added a connections object for preventing duplicates and two helpers to start/stop the connections. // api/socket.ts
import { HubConnection, HubConnectionBuilder, LogLevel } from '@microsoft/signalr';

let connections = {} as { [key: string]: { type: string; connection: HubConnection; started: boolean } };

function createConnection(messageType: string) {
    const connectionObj = connections[messageType];
    if (!connectionObj) {
        console.log('SOCKET: Registering on server events ', messageType);
        const connection = new HubConnectionBuilder()
            .withUrl('API_URL', {
                logger: LogLevel.Information,
                withCredentials: false,
            })
            .withAutomaticReconnect()
            .build();

        connections[messageType] = {
            type: messageType,
            connection: connection,
            started: false,
        };
        return connection;
    } else {
        return connections[messageType].connection;
    }
}

function startConnection(messageType: string) {
    const connectionObj = connections[messageType];
    if (!connectionObj.started) {
        connectionObj.connection.start().catch(err => console.error('SOCKET: ', err.toString()));
        connectionObj.started = true;
    }
}

function stopConnection(messageType: string) {
    const connectionObj = connections[messageType];
    if (connectionObj) {
        console.log('SOCKET: Stoping connection ', messageType);
        connectionObj.connection.stop();
        connectionObj.started = false;
    }
}

function registerOnServerEvents(
    messageType: string,
    callback: (payload: Message) => void,
) {
    try {
        const connection = createConnection(messageType);
        connection.on('NewIncomingMessage', (payload: Message) => {
            callback(payload);
        });
        connection.onclose(() => stopConnection(messageType));
        startConnection(messageType);
    } catch (error) {
        console.error('SOCKET: ', error);
    }
}

export const socketService = {
    registerOnServerEvents,
    stopConnection,
}; So now, our page might look like in the code snippet. We fetch and extract with the list of messages and render them. Also, above registers the event, creates a connection, and listens to the backend. data useEffect NewMessage When the event triggers, the method from the hook updates the existing list with a new object. mutate // pages/chat.ts
import { useChatData } from 'hooks/useChatData';
import { socketService } from 'api/socket';

const Chat: NextPage = () => {
	const { data } = useChatData();

	useEffect(() => {
        socketService.registerOnServerEvents(
            'NewMessage',
            (payload: Message) => {
                mutate(() => [...data, payload], { revalidate: false });
            }
        );
    }, [data]);

	useEffect(() => {
        return () => {
            socketService.stopConnection('NewMessage');
        };
    }, []);

	return (
		<div>
            {data.map(item => (
                <div key={item.id}>{item.content}</div>
            ))}
        </div>	
	);
}; Looks good to me, it works, and we see how new messages appear in the feed. I chose the basic example with chat because it’s clear and easy to understand. And, of course, you apply it on your own logic. Small Bonus Using one of the versions  ( ), we faced a problem with duplications. It was connected to , the dependency array. Each time the dependency was changed, cached callback and triggered it again and again. @microsoft/signalr useEffect connection.on(event, callback); useEffect(() => {
    // data equals [] by default (registerOnServerEvents 1 run),
    // but after initial data fetching it changes (registerOnServerEvents 2 run)
    // each event changes data and triggers runnning of registerOnServerEvents
    socketService.registerOnServerEvents(
        'NewMessage',
		// callback cached
        (payload: Message) => {
		// mutate called multiple times on each data change
            mutate(() => [...data, payload], { revalidate: false });
        }
    );
}, [data]);
// after getting 3 messages events, we had got 4 messages rendered lol The quickest and most reliable solution we found was keeping a copy of data inside the React and using it inside for future updates. ref useEffect // pages/chat.ts
import { useChatData } from 'hooks/useChatData';
import { socketService } from 'api/socket';

const Chat: NextPage = () => {
	const { data } = useChatData();
	const messagesRef = useRef<Message[]>([]);

	useEffect(() => {
	     messagesRef.current = chatData;
    }, [chatData]);

	useEffect(() => {
        socketService.registerOnServerEvents(
            'NewMessage',
            (payload: Message) => {
			    const messagesCopy = messagesRef.current.slice();
                mutate(() => [...messagesCopy, payload], { revalidate: false });
            }
        );
    }, [data]);

	useEffect(() => {
        return () => {
            socketService.stopConnection('NewMessage');
        };
    }, []);

	return (
		<div>
            {data.map(item => (
                <div key={item.id}>{item.content}</div>
            ))}
        </div>	
	);
}; Currently, we use a new version of which it seems already has necessary fixes. But anyway, if someone finds this solution useful and uses this workaround, I will be happy. To conclude, I want to say that my experience with SignalR is quite positive, installation didn’t require any specific dependencies or settings, and it works fine and covers our needs. @microsoft/signalr

Next.js and SignalR: Effortless Socket Integration and Troubleshooting

Next.js এবং SignalR: প্রচেষ্টাহীন সকেট ইন্টিগ্রেশন এবং ট্রাবলশুটিং

Next.js und SignalR: Mühelose Socket-Integration und Fehlerbehebung

Next.js y SignalR: integración de sockets y solución de problemas sin esfuerzo

Next.js et SignalR : intégration et dépannage de sockets sans effort

Next.js और सिग्नलआर: सहज सॉकेट एकीकरण और समस्या निवारण

Next.js と SignalR: 簡単なソケットの統合とトラブルシューティング

Next.js 및 SignalR: 손쉬운 소켓 통합 및 문제 해결

Next.js e SignalR: integração e solução de problemas de soquete sem esforço

Next.js и SignalR: простая интеграция сокетов и устранение неполадок

Next.js ve SignalR: Zahmetsiz Soket Entegrasyonu ve Sorun Giderme

Next.js và SignalR: Khắc phục sự cố và tích hợp ổ cắm dễ dàng

Next.js 和 SignalR：轻松的套接字集成和故障排除

You’ve probably used the command multiple times to test the connection to the server. This is a widely available tool. Have you ever thought about how exactly it works and how to implement it yourself? I find exploring some unknown things helpful in understanding how the system works, and in this article, I'll try to explain how exactly it works and how to recreate it from scratch in ping Node.js. This is not a deep dive by any means, but we will cover some basics on how to implement the binary protocol, manipulate bits, debug network requests, measure time precisely, and more. So let's dive in. What is ping? In case you have never used before, " is a computer network administration software utility used to test the reachability of a host on an Internet Protocol (IP) network... Ping measures the round-trip time for messages sent from the originating host to a destination computer that are echoed back to the source." (c) ping ping wiki Let's give it a try. Just open a terminal and execute . You should see something similar to this: ping 1.1.1.1 $ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=8.322 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=19.255 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=7.433 ms
... Behind the scenes, we send ICMP packets to and await a response. At the same time, we measure the time it takes, TTL, and some statistics across all requests. There is a high chance that you never heard about packets before. This protocol is primarily used by network devices to share operational information. It differs from more common TCP and UDP protocols but works on the same IP stack. Sounds fun, let's dive into implementation details. 1.1.1.1 ICMP Let's take a look at the protocol description on wiki. We will focus on IPv4 for simplicity, but it works similarly for IPv6. A lot is going on here. However, most of the work will be done automatically for us by OS or socket library. Let's focus on the red parts that we will have to implement ourselves. Now we need to figure out how to send those bits and bytes Debugging network with Wireshark Now, we have a good theory behind us to get started. However, to debug our program, it would be helpful to see the actual bits and bytes we send to some IPs. The easiest way to check ANY traffic your machine is using is to use It is free and open-source software that works on both Windows and macOS. Before we start, let's check if theory and practice align on how the protocol works. Wireshark. Two easy steps: Start Wireshark and choose what to capture (in my case wifi that is connected to the Internet) Add filter ICMP in the top bar as it will produce a lot of noise Now execute command in the terminal. This is more or less what you will see: $ ping 1.1.1.1 You can see all requests and responses of the ping command. Even better, Wireshark is quite powerful and knows how to handle ICMP commands. So it will help you parse bits to more meaningful and easier-to-read structures. You can also clearly see the layered structure of network protocols (Ethernet -> IP -> ICMP). This will be very helpful in validating our setup. You can also hover over Packet Bytes to highlight what they are responsible for. In this case, you can see the Type of request is equal to , which is exactly what we would expect from our protocol described above. 8 Let's code Now we have all the building blocks; we can start coding. Unfortunately, Node.js has no native support for raw sockets to use ICMP protocol. However, the npm package supports it using node-gyp to access system-level APIs. raw-socket So practically, we need to: create socket subscribe to messages send messages import raw from "raw-socket";

const socket = raw.createSocket({ protocol: raw.Protocol.ICMP });

socket.on("message", function (buffer, source) {
  // TODO Decode
});

socket.on("error", (e) => {
  console.error("Socket Error: ", e);
  socket.close();
});

const pingBuffer = createPingBuffer(1234, 0, "Payload");
socket.send(pingBuffer, 0, buffer.length, "1.1.1.1", function (error, bytes) {
  if (error) console.error("Unable to send message: ", error.toString());
});

function createPingBuffer(identifier, sequence, payload) {
  // TODO Encode
} This is the main part of the app. Here we create an ICMP socket and start listening for new messages. At the same time, we send our ping command to the IP address. 1.1.1.1 So now we need to implement encoding and decoding of the messages. Encoding ping protocol As you saw in the diagram above, we must provide 8 bytes of information: Type, Code, Checksum, Identifier, and Sequence Number. We can also provide an optional payload that will be returned to us in the response. This will be helpful later. Type = 8 (Request) = 00001000 (binary)
Code = 0 = 00000000 (binary)
Checksum = dynamic value
Identifier = 1 = 0000000000000001 (binary)
Sequence Number = 0 = 0000000000000000 (binary) For clarity, we show this information in multiple rows with a nice table. But just to be clear what we actually send is the following 64 bits: 0000100000000000111101111111111000000000000000010000000000000000 The easiest way to manipulate bits is to use Node.js . It is a subclass of JavaScript's Uint8Array and adds helpful methods to manipulate raw bytes. Buffers const ICMP_HEADER_SIZE = 8;

function createPingBuffer(identifier, sequenceNumber, payload) {
  // Allocate empty 8 bytes buffer filled with 0
  const buffer = Buffer.alloc(ICMP_HEADER_SIZE);

  buffer.writeUInt8(8, 0); // Type 1 byte with offset 0 bytes
  buffer.writeUInt8(0, 1); // Code 1 byte with offset 1 byte
  buffer.writeUInt16BE(0, 2); // Checksum 2 bytes with offset 2 bytes
  buffer.writeUInt16BE(identifier, 4); // Identifier 2 bytes with offset 4 bytes
  buffer.writeUInt16BE(sequenceNumber, 6); // Sequence Number 2 bytes with offset 6 bytes

  // Override 0 checksum with correct value based on full request
  raw.writeChecksum(buffer, 2, raw.createChecksum(buffer));

  return buffer;
} You might notice a weird BE suffix in the function name; it stands for Big-Endian. This is . There are two ways how you can pack multi-byte values in the buffer. This defines which byte should be first/last. endianness That is it! We should be able to send ping requests now. Let's check if it works using Wireshark. As you can see, it works as expected, and we were able to send a request. However, we still need to decode a response Decode ping protocol We can use similar helper methods on the Buffer class to decode the ping packet. However, there is a caveat. We will get a full IP protocol packet as a response. Yet, IP protocol has a dynamic header size. It means we will have to find where our ping message starts. Let's take a closer look at the datagram IHL stands for . It has 4 bits that specify the number of 32-bit (4 bytes) words in the header. Unfortunately, Node.js Buffers lack helper methods to read 4-bit data. It means that we will have to implement it ourselves. Internet Header Length Here we will need to use . To get the last 4 bits of a byte, we will need to use bitwise bitwise operations AND function getIPProtocolHeaderSize(buffer) {
  const versionAndIHL = buffer.readUInt8();
  const IHL = versionAndIHL & 0b00001111; // will remove everything in the first 4 bits -> 0x0000XXXX
  return IHL * 4; // multiply by 4 as it contains number of 32-bit (4 bytes) words to get total size in bytes
} Now we have everything we need to decode a response: function decodePingPacket(buffer) {
  const ipOffset = getIPProtocolHeaderSize(buffer);

  // IP level TTL
  const ttl = buffer.readUInt8(8);

  const type = buffer.readUInt8(ipOffset);
  const code = buffer.readUInt8(ipOffset + 1);
  const checksum = buffer.readUInt16BE(ipOffset + 2);
  const identifier = buffer.readUInt16BE(ipOffset + 4);
  const sequenceNumber = buffer.readUInt16BE(ipOffset + 6);

  return {
    ttl,
    type,
    code,
    checksum,
    identifier,
    sequenceNumber,
  };
} That is it! We need to precisely measure the time between request and response to have a fully functional ping client. Time measurement If you pay closer attention to the original ping implementation, you will notice a special trick to make our client stateless and don't require us to track state for request/response time as ping protocol requires sending back the same payload we send as part of the request. We can send time as part of the payload! This is what the original UNIX implementation did. Unix implementation of ping is open source, so we can learn some tricks from reading . Here, it adds as part of the payload. source code timeval struct timeval {
  time_t      tv_sec;     /* seconds */
  suseconds_t tv_usec;    /* microseconds */
}; Let's use the same approach with our client. We will send a precise time when we send the command and compare it when we get a response. Standard will not work well in this case as we deal with high-precision data. To get accurate time, we can use API. So let's put it into practice and add it to the payload together with the payload itself. Date.now() Performance const time = performance.timeOrigin + performance.now();

const uint32 = new Uint32Array(2);
uint32[0] = time / 1000; // seconds
uint32[1] = (time - uint32[0] * 1000) * 1000; // microseconds

// write it as first 8 bytes of payload
buffer.writeUInt32BE(uint32[0], 8);
buffer.writeUInt32BE(uint32[1], 12);

// write payload itself
buffer.write(payload, 16);

// compute checksum
raw.writeChecksum(buffer, 2, raw.createChecksum(buffer));

return buffer; Conclusion I intentionally simplified some things and cut some corners. Ideally, we will need to add error logging, keep track of statistics, etc. We also need to make sure to filter out all other ICMP packets that are not part of our ping request by . checking the type of request and identifier However, I hope it was an interesting journey on how to implement low-level binary protocols, measure time, debug network requests, do bit manipulations, and read the source code. There is a lot to learn from other open-source projects. I put together all the code here in . It has some extra code to connect all the pieces together. Just run this repo node index.js 1.1.1.1 $ node index.js 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 28 data bytes
36 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=32.622314453125 ms
36 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=9.591552734375 ms
36 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=16.101806640625 ms
...

Building Ping Command in Node.js: Practical Guide to Buffers, Sockets, and Bit Manipulation

When a project needs to be split How do successful projects usually get started? Quickly, without long discussions, in startup mode: we build features and deal with technical debt later. Under such conditions, it’s hard to establish an architecture that would allow the project to continue evolving after 5–7 years. The frontend part of our project was no exception. In this article, I’ll explain how we transitioned from a classic React application to a truly big project. So, we had a typical React 17 app. Redux + logic in thunks and middlewares. Custom SSR on Express. The project was actively growing, attracting new users, and gaining functionality. The complexity of the code increased, and after the Series A round of funding, the company allowed us to allocate up to 15% of our time to technical tasks. At this stage, the product development team began to split into “units”—this is what we call the teams which handle the app’s functionality (a specific user role or scenario). At this point, the frontend project saw its first optimisations: Client-side lazy loading of components
Optimising the Redux middleware call stack These optimisations allowed us to add new features to our React app for a few more years. The project eventually got Series B funding, so the number of frontend developers reached 30 and the size of the main bundle grew to 300 KB. The code's interdependence and task complexity indicated that it was time to break the app into parts. We started by improving the asynchronous loading of components using React Loadable. This allowed us to load not just components asynchronously but entire pages. React Loadable gave us the ability, with our SSR, to understand which parts of the app were touched when rendering the HTML, collect those JS files, and load them before the first client render. After that, we realised that the main issue was in the middleware and thunks, not in the code of our pages. So, we began splitting the business logic within them. Getting started We decided to divide the project into modules using a modern tool for microfrontends. Here are the challenges we faced: SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR.
Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. At this point, we had a 4 KB overhead per module and a few asynchronous pages using the microfrontend tool, but it still didn’t solve the main issue—splitting the business logic. In the end, we put a lot of effort into implementing the tool without gaining significant optimizations. This happened because, regardless of the tool you use, what’s most important is how you logically split the app’s parts. After that, we moved on to directly dividing the business logic, having first solved a few related issues. Data sharing What’s stopping us from separating a module from our app? First of all, the shared stores. Let’s look at this problem using the example of the ‘users’ store. It looks something like this: export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; Each of our future modules uses such a store in roughly the following way. UserIds are stored in objects used by our module, and in selectors, we fill them with data from the users store. Why was it done this way at the start of the project? For convenience, caching, and data normalisation. Data from modules is stored in one place and, in some cases, can be reused from the cache instead of being requested again. The problem is that such a reducer is part of the common store, and if all modules have access to the shared store, it increases module interdependence. So, we extracted such reducers into separate stores using Zustand. This allowed us to isolate modules from data they didn’t need, while maintaining data sharing and reactivity between modules. Event sharing between modules The next issue we solved was shared middleware. Let’s break this down using the example of socket middleware. As the name suggests, this middleware processes events coming through a WebSocket connection. The problem is that this single middleware processes events for the stores of almost all modules. We reorganized it as follows: we created a separate event bus based on EventEmitter, independent of Redux, and now the module that maintains the WebSocket connection produces messages straight into the event bus. This way, we managed to split the common logic and distribute it across modules. An important point here: when switching from dispatching events to EventEmitter, you don’t need to migrate all events, just those used in multiple modules. Events that happen and are handled within one module don’t need to be migrated to EventEmitter. It’s crucial to understand the list of modules you want to isolate. A few more things to mention Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render.
In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. After solving these issues, we began splitting the business logic into modules, reflecting the structure of how our company is divided into teams and areas of responsibility. Conclusion Our mistake was starting with a tool before logically dividing the modules. The correct order for modularisation in our case would have been: Logically divide the project into modules: make a list of modules.
Solve the main issues with shared stores, events, and the base component library.
Actually split the business logic.
Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. And in conclusion, I want to wish good luck to everyone who is starting to split their application into modules. It's a long journey, but the result is worth it. When a project needs to be split When a project needs to be split How do successful projects usually get started? Quickly, without long discussions, in startup mode: we build features and deal with technical debt later. Under such conditions, it’s hard to establish an architecture that would allow the project to continue evolving after 5–7 years. The frontend part of our project was no exception. In this article, I’ll explain how we transitioned from a classic React application to a truly big project. So, we had a typical React 17 app. Redux + logic in thunks and middlewares. Custom SSR on Express. The project was actively growing, attracting new users, and gaining functionality. The complexity of the code increased, and after the Series A round of funding, the company allowed us to allocate up to 15% of our time to technical tasks. At this stage, the product development team began to split into “units”—this is what we call the teams which handle the app’s functionality (a specific user role or scenario). At this point, the frontend project saw its first optimisations: Client-side lazy loading of components Optimising the Redux middleware call stack Client-side lazy loading of components Optimising the Redux middleware call stack These optimisations allowed us to add new features to our React app for a few more years. The project eventually got Series B funding, so the number of frontend developers reached 30 and the size of the main bundle grew to 300 KB. The code's interdependence and task complexity indicated that it was time to break the app into parts. We started by improving the asynchronous loading of components using React Loadable. This allowed us to load not just components asynchronously but entire pages. React Loadable gave us the ability, with our SSR, to understand which parts of the app were touched when rendering the HTML, collect those JS files, and load them before the first client render. After that, we realised that the main issue was in the middleware and thunks, not in the code of our pages. So, we began splitting the business logic within them. Getting started Getting started We decided to divide the project into modules using a modern tool for microfrontends. Here are the challenges we faced: SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR. Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR. SSR Build Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. Integration with Loadable At this point, we had a 4 KB overhead per module and a few asynchronous pages using the microfrontend tool, but it still didn’t solve the main issue—splitting the business logic. In the end, we put a lot of effort into implementing the tool without gaining significant optimizations. This happened because, regardless of the tool you use, what’s most important is how you logically split the app’s parts. After that, we moved on to directly dividing the business logic, having first solved a few related issues. Data sharing Data sharing What’s stopping us from separating a module from our app? First of all, the shared stores. Let’s look at this problem using the example of the ‘users’ store. It looks something like this: export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; Each of our future modules uses such a store in roughly the following way. UserIds are stored in objects used by our module, and in selectors, we fill them with data from the users store. Why was it done this way at the start of the project? For convenience, caching, and data normalisation. Data from modules is stored in one place and, in some cases, can be reused from the cache instead of being requested again. The problem is that such a reducer is part of the common store, and if all modules have access to the shared store, it increases module interdependence. So, we extracted such reducers into separate stores using Zustand. This allowed us to isolate modules from data they didn’t need, while maintaining data sharing and reactivity between modules. Event sharing between modules Event sharing between modules The next issue we solved was shared middleware. Let’s break this down using the example of socket middleware. As the name suggests, this middleware processes events coming through a WebSocket connection. The problem is that this single middleware processes events for the stores of almost all modules. We reorganized it as follows: we created a separate event bus based on EventEmitter, independent of Redux, and now the module that maintains the WebSocket connection produces messages straight into the event bus. This way, we managed to split the common logic and distribute it across modules. An important point here: when switching from dispatching events to EventEmitter, you don’t need to migrate all events, just those used in multiple modules. Events that happen and are handled within one module don’t need to be migrated to EventEmitter. It’s crucial to understand the list of modules you want to isolate. A few more things to mention A few more things to mention Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render. In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render. In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. After solving these issues, we began splitting the business logic into modules, reflecting the structure of how our company is divided into teams and areas of responsibility. Conclusion Conclusion Our mistake was starting with a tool before logically dividing the modules. The correct order for modularisation in our case would have been: Logically divide the project into modules: make a list of modules. Solve the main issues with shared stores, events, and the base component library. Actually split the business logic. Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. Logically divide the project into modules: make a list of modules. Solve the main issues with shared stores, events, and the base component library. Actually split the business logic. Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. And in conclusion, I want to wish good luck to everyone who is starting to split their application into modules. It's a long journey, but the result is worth it.

Our Journey to Micro-Frontends

React is Not Really Reactive. Let's Fix That With RxJS!

How to Build a High-Performance TCP Server from Scratch

OpenShift Virtualization: Unify, Manage and Scale Hybrid Cloud

The MinIO DataPod: A Reference Architecture for Exascale Computing

MinIO DataPod: Exascale Computing এর জন্য একটি রেফারেন্স আর্কিটেকচার

Der MinIO DataPod: Eine Referenzarchitektur für Exascale-Computing

MinIO DataPod: una arquitectura de referencia para la computación a escala de exaescala

Le MinIO DataPod : une architecture de référence pour le calcul exascale

मिनियो डेटापॉड: एक्सास्केल कंप्यूटिंग के लिए एक संदर्भ आर्किटेक्चर

MinIO DataPod: エクサスケール コンピューティングのリファレンス アーキテクチャ

MinIO DataPod: 엑사스케일 컴퓨팅을 위한 참조 아키텍처

O MinIO DataPod: Uma Arquitetura de Referência para Computação em Exaescala

MinIO DataPod: эталонная архитектура для эксафлопсных вычислений

MinIO DataPod: Exascale Hesaplama için Bir Referans Mimarisi

MinIO DataPod: Kiến trúc tham chiếu cho điện toán Exascale

MinIO DataPod：百亿亿次计算的参考架构

Stories, News & Mentions about SPOCKET

Spocket’s Stories on HackerNoon