Михаил Р.

Зайти в консоль разработчика, выбрать вкладку Network, поставить галочку Preverse log, отправить сообщение и смотреть результат.

скрипт придется компилировать, либо заранее либо таскать с собой golang (гуглить: portable golang) если же нужно еще и оффлайн, то заранее подгрузи нужные зависимости
запуск приложения из electron:

var child = require('child_process').execFile;
var executablePath = "myapp.exe";
var parameters = ["--my_param"];

child(executablePath, parameters, function(err, data) {
     console.log(err)
     console.log(data.toString());
});

1. Менять руками в коде.
2. Написать бек c нуля на php/python/nodeJS/Java
3. Использовать готовую цмс (которую вы, кстати, указали в тегах)

В первом примере вы не конвертируете байты в строку и обратно. Вы конвертируете байты в их хекс-коды, а потом еще раз конвертируете результат в хекс-коды. Логично, что у вас не получается одинаковой строки, ибо вы два раза кодируете и ни одного раза не декодируете.
Если вам нужно положить какие-то бинарные данные во что-то, что поддерживает только ASCII-текст, используйте лучше base64.
https://go.dev/play/p/NPrAMrsHZje

package main

import (
	"encoding/base64"
	"fmt"
)

func main() {
	srcString := "Привет, тут есть юникод"
	fmt.Println("Исходный текст:", srcString)

	codedStr := base64.StdEncoding.EncodeToString([]byte(srcString))
	fmt.Println("После кодирования:", string(codedStr))

	resBytes, err := base64.StdEncoding.DecodeString(codedStr)
	if err != nil {
		fmt.Println("Ошибка декодирования:", err)
		return
	}
	resString := string(resBytes)
	fmt.Println("После декодирования обратно:", resString)
}

Почему Kafka? Почему микросервисы?

1. Принимает запрос и отправляет его в kafka.

От кого принимает и каким образом? Какой выдается ответ и каким образом?
Нужно разделить интернет-магазин на логические части. Проверить какие запросы могут обслуживаться синхронно, а какие - отложенно (асинхронно).
Когда на складе остается мало товара, пользователь должен знать об этом. Еще можно показывать наличие товара только если имеется свыше X единиц. А с точки зрения СУБД можно применить оптимистическую блокировку записи.

Так как вы хотите сделать не получится если отсутствует break, проверка не выполняется - отрабатывают все инструкции после первого true.

А зачем нужны библиотеки?

let data = '12345678901234567890123456789012';
let base64data = Buffer.from(data).toString('base64');

console.log(base64data); // MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=

Несмотря на то, что эти инструменты созданы для решения одних и тех же проблем, делают они это по-разному, как под капотом, так и в плане предлагаемых абстракций. Потому нельзя сказать что async/await в C# - это "просто обертка над горутинами".

Горутины в Go - это концепция stackful coroutines (под капотом) + CSP (в абстракциях). Каждый раз, когда мы создаём горутину, под неё выделяется отдельный стек вызовов для её собственных нужд. При этом, когда происходит паника, то stack unwinding (размотка стека вызовов) происходит только в пределах этой горутины и не покидает границ её стека. Стек горутины полностью отвязан от стека её создания/вызова, потому горутина не может возвращать результат. Любое общение между горутинами выполняется либо посредством каналов, либо какой-то общей памяти.

async/await в C# (то есть, Task'и) - это концепция stackless coroutines (под капотом) + futures (в абстракциях). Код с async/await'ами компилятор превращает в определенную стэйт-машину с yield point'ами. У них нет отдельного стека, они выполняются в том же стеке что и вызывающий их код. Соотвественно, есть возможность словить exception'ы (аналог panic'и) возникающие внутри асинхронного Task'а прямо в запускающем его коде. Так как выполнение идёт на том же стеке - Task нормально может возвращать результат и мы его можем считать в вызывающем коде без дополнительных примитивов/инструментов.

При этом, если мы запустим Go с GOMAXPROCS=1, то мы получим однопоточный асинхронный код в Go (по умолчанию он многопоточный). Также и в C# мы можем выполнять Task'и как на одном потоке, так и на thread pool, получая аналогичные Go гарантии рантайма.

С точки зрения абстракций/использования - это уже вкусовщина. Кому как больше нравится. У futures лучше дизайн в плане composability (их эргономичнее join'ить и select'ить), но они вынуждают писать везде async и await. У горутин надо постоянно городить чехарду с синхронизацией (попробуйте сделать аналог await для произвольной горутины), но если эту чехарду прятать под капот (как обычно и делают), то код вообще выглядит полностью синхронным и программисты радуются.

contents := []byte("Hello World")

// write a password zip
raw := new(bytes.Buffer)
zipw := zip.NewWriter(raw)
w, err := zipw.Encrypt("hello.txt", "golang")
if err != nil {
    log.Fatal(err)
}
_, err = io.Copy(w, bytes.NewReader(contents))
if err != nil {
    log.Fatal(err)
}
zipw.Close()

Создаст архив в формате .zip с файлом hello.txt и паролем golang
Взято с официальной документации (от сюда).

Смотрите, главное различие между ними это количество ядер
У 5600G - 6 ядер/12 потоков
У 5700G - 8 ядер/16 потоков

Еще у 5700 более мощная видеокарта встроена.

Собственно далее вопрос: у вас, в вашей нагрузке будет чем утилизировать эти дополнительные 2 ядра/4 потока? Это либо задачи, которые хорошо параллелятся, либо большое количество процессов (виртуальные машины, например). Я в свое время взял 1700 первого поколения именно из-за этих дополнительных ядер по сравнению с 1600. Собственно никаких проблем с пиковой загрузкой проца не имею. Может быть хватило бы и 6 ядер, может быть и 4. Но, поскольку комп я брал надолго (и мне его более чем хватает на данный момент), то решил брать максимально доступную конфигурацию (был еще Threadripper, но его цена чуть более чем неприличная).

Занимаюсь разработкой на Java и время от времени играю в не особо требовательные игры.

Лично я при таких условиях взял бы 5700, но решать разумеется вам.