Я для пет проекта при переходе на golang написал самообновляющийся выключатель компов по сетке (есть на гитхабе моем) Также хорошо написать какой-то парсер проксей или парсер чего-то на headless chrome (есть такой, правда не выложено нигде) Как вариант - линтер protobuf файлов (есть на гитхубе) Генератор фикстур с русскими ФИО (есть на гитхубе) oshokin в гитхубе
@@VyacheArt Спасибо. У тебя тоже прикольные недушнявые видосики. Жаль, что редко выкладываешь. Ещё как вариант для пет проекта - написать бекенд социальной сети, а потом его скейлить - репликацию, шардирование, кеш, нагрузочные тесты прикрутить. Нарисовать графики, ну и задеплоить это дерьмо. Тут все технологии и потрогаешь сразу - docker, k6, grafana, prometheus, postgres, makefile, bash, gitlab ci.
А почему боль?) Мне кажется неважно как будет идти общение с базой в пет проекте, его всегда можно переписать 🙂 Это просто инструмент, который упрощает взаимодействие ценой производительности, ну и может не слишком go-way получается из-за "магии") но для начала мне кажется вообще без разницы так, или с билдером 🙂
@@VyacheArt нет конечно может в таком подходе есть смысл))) как говорят переучиваться сложней, чем делать сразу "правильно", но в случаях с ормками в го тут наоборот, спрыгиваешь с охотой и достаточно легко)))
Если сделать слоистую архитектуру, тогда просто будешь менять только репозиторий, не трогая остальное. То есть надо делать по общеизвестным правилам и принципам например соблюдая SOLID. Если нравится делать кашу, тогда хотя бы код который отвечает за работу с бд держи в одном месте (отметь комментарием начало и конец) или в одном файле
А для кэширования разве не используется redis или memcached? Просто странно хранить кэш в оперативке, если балансировщик нагрузки и так запросы между инстансами случайно раскидывает. На много логичнее сделать хранение в общей бд по типу ключ значение, тем более что запрос в датацентрах от сервера с бэкендом до бд идет 1мс (Спрашивает фронтендер)
В реальном проекте да, лучше redis или другое популярное решение, которое не придётся поддерживать. Но в ролике речь о первых проектах, сделав которые можно сильно прокачаться. По поводу странности кеша в оперативке не уловил, и про какие датацентры идёт речь тоже не очень понял. Если речь о том, что лучше кеш в редисе на отдельной тачке, вместо мапы, то это не всегда так. 1 мсек - много для каких-нибудь высоконагруженных серверов, ближе будет лучше, если позволяют ресурсы.
Я для пет проекта при переходе на golang написал самообновляющийся выключатель компов по сетке (есть на гитхабе моем)
Также хорошо написать какой-то парсер проксей или парсер чего-то на headless chrome (есть такой, правда не выложено нигде)
Как вариант - линтер protobuf файлов (есть на гитхубе)
Генератор фикстур с русскими ФИО (есть на гитхубе)
oshokin в гитхубе
Офигенно, спасибо, что поделились своими идеями!
@@VyacheArt Спасибо. У тебя тоже прикольные недушнявые видосики. Жаль, что редко выкладываешь.
Ещё как вариант для пет проекта - написать бекенд социальной сети, а потом его скейлить - репликацию, шардирование, кеш, нагрузочные тесты прикрутить. Нарисовать графики, ну и задеплоить это дерьмо. Тут все технологии и потрогаешь сразу - docker, k6, grafana, prometheus, postgres, makefile, bash, gitlab ci.
спасибо за видео!! у вас очень приятный для слуха тембр голоса
Успехов в создание очередного шедевра 😊💋🤭
Спасибо за Ваш труд! ❤ 💥 как всегда! Дальнейших успехов!
Спасибо!
Спасибо, очень полезно.
кайф, спасибо!)
Очень полезно ❤🥹🥹😉🥹 круто! 👍 💣 жду новый ролик! ❤
ураааааа, новое видео !
Спасибо:)
Какие курсы ты бы порекомендовал новичку в Go? Знаю только JS не очень глубоко. Хочу изучить Go и писать на нём
нееет пажалуйста нееет горм за чтоооо) давайте советовать какие нибудь квери билдеры нуждающимся, но не ормки для го это такая боль!)
А почему боль?)
Мне кажется неважно как будет идти общение с базой в пет проекте, его всегда можно переписать 🙂
Это просто инструмент, который упрощает взаимодействие ценой производительности, ну и может не слишком go-way получается из-за "магии") но для начала мне кажется вообще без разницы так, или с билдером 🙂
@@VyacheArt нет конечно может в таком подходе есть смысл))) как говорят переучиваться сложней, чем делать сразу "правильно", но в случаях с ормками в го тут наоборот, спрыгиваешь с охотой и достаточно легко)))
@@ArtemCYOU для MVP пойдёт. Если бд будет узким местом то можно переписать репозитори. Мне нравится sqlc
Если сделать слоистую архитектуру, тогда просто будешь менять только репозиторий, не трогая остальное. То есть надо делать по общеизвестным правилам и принципам например соблюдая SOLID. Если нравится делать кашу, тогда хотя бы код который отвечает за работу с бд держи в одном месте (отметь комментарием начало и конец) или в одном файле
А grpc для js или ts есть? У нас grpc используется для межсервисного взаимодействия, и не совсем в курсе.
Есть! grpc.io/docs/languages/node/
А для кэширования разве не используется redis или memcached? Просто странно хранить кэш в оперативке, если балансировщик нагрузки и так запросы между инстансами случайно раскидывает. На много логичнее сделать хранение в общей бд по типу ключ значение, тем более что запрос в датацентрах от сервера с бэкендом до бд идет 1мс (Спрашивает фронтендер)
В реальном проекте да, лучше redis или другое популярное решение, которое не придётся поддерживать.
Но в ролике речь о первых проектах, сделав которые можно сильно прокачаться.
По поводу странности кеша в оперативке не уловил, и про какие датацентры идёт речь тоже не очень понял.
Если речь о том, что лучше кеш в редисе на отдельной тачке, вместо мапы, то это не всегда так. 1 мсек - много для каких-нибудь высоконагруженных серверов, ближе будет лучше, если позволяют ресурсы.
@@VyacheArt Правильно, Redis годная вещь быстрая и жрет мало памяти, сам пробовал, но только в качестве PubSub
Такое чувство, что это видео сгенерировал ai
Почему?)
Так и есть...
если б всё было так просто, не нужно было бы делать сценарий, инфографику и сниматься, то я б любые деньги за такой AI отдал 😂
В случае с ИИ глаза бы смотрели в камеру, а не на сценарий