Ну ладно, поищу ещё что-нибудь, всем спасибо

да, там сразу непонятно ваще че куда

Ребят, у кого-нибудь есть ссылка на проект Rails + webpacker react? Просто пытаюсь разобраться со структурой, и в принципе как правильно. Гуглёж выводит на старые проекты, где react-rails, а я не это хочу

https://github.com/tai2/webpacker-react-example во, я нашел тебе нормальный пример

там и вебпакер 3 и конфиг годный, через вебпакеровское апи

Спасибо

только там тайпскрипт ?

Начиная банально с того, где какие файлы лежат

тебе скорее надо смотреть на структуру проектов на реакте нежели связки с рельсами

нене, надо именно связки

потому что просто реакт и реакт с рельсами - там везде свои нюансы

Вот да

как в рубях можно получить все локальные диски(и файлы в них) + тоже самое и для сетевых ПК, то есть подключенных к одной сети. Подскажите пожалуйста, как можно это сделать? ОС винда

как в рубях можно получить все локальные диски(и файлы в них) + тоже самое и для сетевых ПК, то есть подключенных к одной сети. Подскажите пожалуйста, как можно это сделать? ОС винда

скорее всего ты используешь не тот инструмент =)

ну то есть вероятно ты сможешь это как-то сделать на руби, но будет убого и со страданиями

тебе нужен какой-нить .Net

скорее плюсы

у них из коробки все это норм работает как с вин так и с юникс

сильно хардкорно все-таки

если нужна только винда, то лучше .Нет

а шарп?

а ну шарп да

если нужна только винда, то лучше .Нет

только винда

я собстна шарп и имел в виду

думаю одно - пишу другое

спасибо

как в рубях можно получить все локальные диски(и файлы в них) + тоже самое и для сетевых ПК, то есть подключенных к одной сети. Подскажите пожалуйста, как можно это сделать? ОС винда

https://stackoverflow.com/questions/3258518/ruby-get-available-disk-drives

https://stackoverflow.com/questions/3258518/ruby-get-available-disk-drives

это ж только подключенные сетевые диски. а я так понял надо еще сеть сканить и там все шары доставать

Вообще я пологаю что digital signature это надстройка над asymmentric encription где названия названия ключей поменяли. pulic encript key для asymentric encripton стал private для digital signature.

Asimmetric encritption: https://youtu.be/8I7BNgD2Yag Digital signature: https://youtu.be/TmA2QWSLSPg

Digital signature это зеркальное отражение названий Asymmetric Encription, но по сути дела одно и тоже.

Народ, а объясните мне за микросервисы? На данный момент в проекте примерно 10 воркеров сайдкика, из которых 3 штуки работают автономно (запускаются при старте приложения, и сами себя планируют, как аналог крона), и остальные дергаются из приложения. Будут ли плюсы, если перейти на микросервисы? И какие вообще best practices есть?

Народ, а объясните мне за микросервисы? На данный момент в проекте примерно 10 воркеров сайдкика, из которых 3 штуки работают автономно (запускаются при старте приложения, и сами себя планируют, как аналог крона), и остальные дергаются из приложения. Будут ли плюсы, если перейти на микросервисы? И какие вообще best practices есть?

Холиварная тема

Подскажите плз, можно что-то тип такого сделать? https://gist.github.com/KirillFurtikov/83435e56452bd9cdab4f5b1d97a533c9 Т.е вернуть объект, метод которого вызывался

Имхо, лучше сервисная чем микросервисная

Холиварная тема

понимаю, но хочется для себя услышать мнения от людей, кто уже имел возможность сравнить

Имхо, лучше сервисная чем микросервисная

А чем они отличаются?

или это монолит + микросервисы?

Идеология микросервисов - любой функционал который можно вынести в микросервис - выводим в микросервис

В сервисах выводим только то, что не зависит от других сервисов

В сервисах у каждого сервиса своя версионность и свой флоу разработки

В микросервисах общий

Но это все субъективное разделение

Так вот в микросервисах гигантское время занимает их отладка

Это если про основной недостаток

Ну если просто распилить монолит на микросервисы как по первому определению, то да - так и будет

Идеология микросервисов - любой функционал который можно вынести в микросервис - выводим в микросервис

есть еще промежуточный вариант - все что можно вынести в отдельный независимый модуль/класс - выносится, который спокойно может быть трансформирован в микросервис

Потому что под новую структуру микросервисов логику не переделали. Как был монолит, так и остался, только размазанный по системе

Народ, а объясните мне за микросервисы? На данный момент в проекте примерно 10 воркеров сайдкика, из которых 3 штуки работают автономно (запускаются при старте приложения, и сами себя планируют, как аналог крона), и остальные дергаются из приложения. Будут ли плюсы, если перейти на микросервисы? И какие вообще best practices есть?

А чего ты хочешь достичь перейдя на микросервисную архитектуру? Бест пректис - все зависит.

есть еще промежуточный вариант - все что можно вынести в отдельный независимый модуль/класс - выносится, который спокойно может быть трансформирован в микросервис

Ага, только обычно этим пренебрегают

И херачат микросервисы :)

Идеология микросервисов - любой функционал который можно вынести в микросервис - выводим в микросервис

Отлично, тогда они точно не нужны)

А чего ты хочешь достичь перейдя на микросервисную архитектуру? Бест пректис - все зависит.

В общем, как оказалось, я не хочу переходить на микросервисы. А хочу как-то более правильно организовать работу уже с существующим кодом, который исполняется асинхронно

Идеология микросервисов в том, чтобы создать приложение поделенное логически так, что каждая часть приложения работает независимо от состояния других.

Можно будет куски менять на лету. Делать горизонтальное масштабирование, резервирование и тд

переписывать куски на других языках ?

И это тоже

Так. А что лучше тогда? Сайдкик, или что-то с очередью сообщений?)

Мы тут у себя для телефонии пару модулей из монолита на С сделали микросервисами. Верней делал я. И каждый из новых микросервисных модулей можно переписать на чем угодно, потому что они общаются через стандартные интерфейсы. И даже если ляжет все, кроме точки попадания клиента в это приложение - он просто решит что ему не ответили по телефону

Так. А что лучше тогда? Сайдкик, или что-то с очередью сообщений?)

так, насколько я понимаю, sidekiq это и есть очередь сообщений

Так. А что лучше тогда? Сайдкик, или что-то с очередью сообщений?)

По-моему у тебя и так все ОК.

Вопрос в том что хотят получить в конечном итоге)

думаю если подумать то sidekiq это сервис

я тут неуверне конечно

микросервис в моем понимании это маленький кусок приложения который можно переписать за пару дней на другой язык.

который работает и деплоится отдельно

Вопрос в том что хотят получить в конечном итоге)

Вопрос пока такой: нормально ли, что в сайдкике есть воркеры, которые работают независимо от основного софта? Ну и собственно нету например возможности приостановить, или как-то управлять этими воркерами.

Как это как то мешало до этого?

так, насколько я понимаю, sidekiq это и есть очередь сообщений

Не совсем. Она как бы сделана с использованием key-value БД

Как это как то мешало до этого?

Не мешало. Но хочется более совершенную архитектуру, сделать лучше если возможно сделать, и если имеет смысл это делать

микросервис в моем понимании это маленький кусок приложения который можно переписать за пару дней на другой язык.

Несколько воркеров удовлетворяют этому определению

Не мешало. Но хочется более совершенную архитектуру, сделать лучше если возможно сделать, и если имеет смысл это делать

Эммммм. Это так не работает

Вот чем вы сейчас пытаетесь заниматься)

Трогать архитектуру надо если: 1) Текущая архитектура не отвечает потребностям 2) Выгода от изменения архитектуры превышает затраты по её замене

Трогать архитектуру надо если: 1) Текущая архитектура не отвечает потребностям 2) Выгода от изменения архитектуры превышает затраты по её замене

+++

зачастую микросервисы выделяют для масштабирования

и как только появляется слой микросервисов - сразу начинаются новые проблемы, еще не решенные.

транспортный уровень например.

Ну у нас все равно пришлось бы переписывать. Просто микросервисность слишком много вкусного дала, чтобы с ней работать

Имею в виду или старый монолит в новом окружении сделать или микросервисы вместо монолита

Трогать архитектуру надо если: 1) Текущая архитектура не отвечает потребностям 2) Выгода от изменения архитектуры превышает затраты по её замене

так вот я и пытаюсь щас понять все плюсы и минусы, применяемость

Ну и есть воркеры, которые вероятнее всего когда-нибудь придется вынести в отдельный процесс или отдельный сервер.

Неа - не пытаетесь. Вы чтото слышали о микросервисах, чтото о том как работает сайдкик и спрашиваете у окружающий - "А объясните мне зачем мне стоит одно на другое поменять?"

я кстати до начала года путал сервисы и микросервисы

Неа - не пытаетесь. Вы чтото слышали о микросервисах, чтото о том как работает сайдкик и спрашиваете у окружающий - "А объясните мне зачем мне стоит одно на другое поменять?"

Преувеличиваете, барин. Человек с одним работал, а со вторым - нет. Пытается понять насколько в будущем такая замена может облегчить жизнь. Ну и, как Алекс, тоже может что-то путать.

Ну и есть воркеры, которые вероятнее всего когда-нибудь придется вынести в отдельный процесс или отдельный сервер.

Даже тут "вероятней всего" "когда нибудь". То есть вы сами толком не знаете. Но беретесь решать несуществующую проблему

Неа - не пытаетесь. Вы чтото слышали о микросервисах, чтото о том как работает сайдкик и спрашиваете у окружающий - "А объясните мне зачем мне стоит одно на другое поменять?"

Не зачем. А стоит ли пробовать очередь сообщений вместо него.

Если человек хочет узнать что такое микросервисы он берет нормальную книгу по ним и изучает. А то, что тут человек пытается сделать - детский сад

Даже тут "вероятней всего" "когда нибудь". То есть вы сами толком не знаете. Но беретесь решать несуществующую проблему

Давайте перейдем к конкретике. Есть сервис, который отвечает за отправку почты клиентам. Допустим, щас задействованы 1000 человек, завтра 500 тысяч будет. Если я сказал, что потребность в масштабировании есть — это не означает что она нужна прям вот щас.

Не зачем. А стоит ли пробовать очередь сообщений вместо него.

Еще раз. Что у вас в проекте делают воркеры. Почему это так было реализовано. Может ли очередь сообщений их заменить. Для чего вы хотите внедрить очередь сообщений. Сами для себя сначала на эти вопросы ответьте и поймете оно вам надо или нет

Если человек хочет узнать что такое микросервисы он берет нормальную книгу по ним и изучает. А то, что тут человек пытается сделать - детский сад

Если вы не можете дать аргументированный ответ —может не стоит переходить на сарказм?

Написав в группу, я ожидал "за" и "против" на основе реального опыта

Давайте перейдем к конкретике. Есть сервис, который отвечает за отправку почты клиентам. Допустим, щас задействованы 1000 человек, завтра 500 тысяч будет. Если я сказал, что потребность в масштабировании есть — это не означает что она нужна прям вот щас.

Если 1000 человек создают нагрузку в 0,0001% на сервер то смысла вообще нет. Тем более если нагрузка вырастет "когда нибудь в будущем"