там ничего нового. сделал апи вызов - отправил данные для чека (список позиций + разную налоговую требуху). тебе в ответ ссылку куда юзера редиректить. редиректишь юзера и ждешь когда платежная система пришлет вебхук что оплата прошла или не прошла... всё...
Большой запрос к этой теме только изза того что это частый пункт в вакансиях, не смотря на то что за этим пунктом практически ничего особонного не кроется. Даже если совсем никогда не работали с микросервисами, не будет никахих проблем с тем что бы просто начать с ними работать, сложного вообще нет ничего.
Добрый день! Очень толковые видео. Я знаю, что на канале есть видео про docker, но хотелось бы глубже капнуть, с полноценной базой (не лайт), как вести разработку на локалке (например открыть проект в phpstorm и, чтобы он крутился на docker (я xampp сейчас пользуюсь), возможно даже установка на прод. Как-то не вся картинка в голове сложилась. Может, конечно, это только у меня)
Интересно послушать про Symfony в сравнении с Laravel если у вас был опыт его использования. Кст для микросервисов он думаю больше подходит относительно ларавеля.
По поводу SCALING, то, что вы сказали это не совсем то. SCALING подразумевает, что вы можете запустить несколько экземпляров одного и того же микросервиса, причем, даже не обязательно, что они будут запущены на одной и той же физической машине. Соответственно это одно из требований к стилю написания микросервиса, если сервис хранит, что-то важное в своей памяти, то это за микросервис считать нельзя, по этому бы критерию я и делил монолитные сервисы и микросервисы.
Интересно ещё научиться делать какие-то свои пакеты в композиции и их подключать в своих проектах. Ну например какие-то хелперы сделать и в свой гит залить. А потом в свой проект этот репозиторий подключать и юзать. Вот это интересно и полезно
Как же замечательно что проходит мода на эти микросервисы.. Некоторые доходят до абсурда, делают 1 сервис для 1й функции, бьют в грудь мол это быстрее, легче обслуживать и тд. Я конечно специально не искал, но... Первое нормальное объяснение по делу. Автор, обнял подкинул тебя, от души прям!
Ну не знаю, твой пример конечно дичь, но учитывая сколько времени существует эта концепция и насколько она не проработана, даже такой вариант не так уж плох. Мы с товарищем хотели сделать микросервисный пэт, первым делом столкнулись с сотнями архитектур, казалось бы, столько времени прошло, а до сих пор столько говна
@@laravelcreative Оплаты, формирование чеков, вебхуки и тд. Понятно, что у каждого банка свои правила, но на стороне сайта +- должна быть одинаковая архитектура. (мб нет и я ошибаюсь, поэтому и прошу рассказать). UPD: как минимум такие фичи, как та, что сумму переводят в копейки, чтобы при математических операциях не потерялись знаки после запятой, потому что php не очень точный на них. А потом возвращают обратно к рублям.
По плюса у монолита: 1. Высокая производительность, чего? Информационной системы, то нет, монолит в сравнении с сервисным подходом не обладает высокой производительностью, ибо подключение ко всем возможным происходит там. 2. Быстрый старт - ок. 3. Лёгкая поддержка. Под очень большим вопросом, особенно если, ломается, что-то в монолите он перестает весь работать. 4. Интеграция сотрудников в сравнении с микросервисами сложнее. 5. Ошибку найти в простом легче, чем в сложном. Если микросервис простой как пробка в нем и ошибок то особо быть не может. 6. CI/CD вопрос docker а не вопрос монолита или микросервиса.
@@laravelcreative ага практики с микросервисами больше 5 лет, а с монолитами около 8 лет, до изучения docker docker-swarm и k8s, делал только монолиты. Теперь на любой монолитный сервис смотрю, как на кусок больших и потенциальных проблем.
Понятно. Речь про производительность - это про подзапросы, которые увеличивают в целом время ответа. Монолит не делает подзапросы. Остальные пункты - в видео был акцент, что когда монолит разрастается, то его преимущества с повышением хаоса теряются. Вопрос ci/cd обычно всегда выставляется, как один из основных аргументов для перехода в микросервисы. Для видео использовал не только свой опыт, но и сделал выборку других специалистов. У вас видимо по другому, чему я конечно рад.
@@laravelcreative я вас не упрекаю, не в коем случае, не в компетенции, я выражаю своё мнения и только, исходя исключительно из своего опыта. Но про производительность, я так и не понял вашу позицию. О каких подзапросах идет речь?
3:50 вы кажется немного сами не понимаете что такое микросервис что такое монолоит. Слова состоит из монолитов вообще настораживает. Картинки от одного блогера переходят к другому....только в фотошоп цвета меняют.
@@laravelcreative , спасибо за труд. Я пока видео ждал, микросервис на ребите написал (Ларка/ Ларка). Но курс крайне необходимый, особенно в современных реалиях и требованиях к вакансиям.
@@alexandr9900 этот фреймворк предназначен чтобы отдать заказы быстро сделав тяп ляп. Нормального ООП, соблюдение паттернов нету. Для более серьёзных проектов используются Symfony, Laravel.
Ну да, микросервисы не увеличивают производительность, а сам факт того, что если большому количеству пользователей нужен один функционал, мы можем не иницализировать работу всего остального кода? А ещё тот факт, если будет большая нагрузка например на микросервис чатов, мы можем отдельно отмасштарбировать отдельно его а не всю платформу?
5:15. Человек рассказывает о том, что распределение информационной системы не влияет на производительность 🤦 Как микросервисная архитектура может снижать производительность системы? Если она на РЕСТе, то контроллеры просто работают асинхронно. Если же на очередях - RabbitMQ или Kafka спасут мир, правда? А система разгрузится за счёт того, что один запрос никогда не будет проходить через все серверы. В худшем случае через 2-3 (за исключением фронтенда и БД), но это не так долго, правда? Если шла речь о снижении производительности для пользователя... ну извините, но это незаметно. А вот в случае с монолитом при увеличении количества пользователей... Не буду продолжать
Уважаемый Автор благодарю Вас! Продолжайте пожалуйста!
Благодарю)!
Продолжайте! Never give up!
Расскажи про платежные системы. Базу. Что самое важное
В будущем:)
там ничего нового.
сделал апи вызов - отправил данные для чека (список позиций + разную налоговую требуху). тебе в ответ ссылку куда юзера редиректить.
редиректишь юзера и ждешь когда платежная система пришлет вебхук что оплата прошла или не прошла...
всё...
Автор сделай курс по микросервисам на рабит мк.
Уже:)
Большой запрос к этой теме только изза того что это частый пункт в вакансиях, не смотря на то что за этим пунктом практически ничего особонного не кроется. Даже если совсем никогда не работали с микросервисами, не будет никахих проблем с тем что бы просто начать с ними работать, сложного вообще нет ничего.
да продолжай че на пол пути останавливаться
Благодарю)!
Пожалуйста продолжайте это очень редкая тема , очень нуждаюсь
Благодарю!)
продолжай, продолжай, ПРОДОЛЖА-А-А-А-Й!
Благодарю)!
Можно еще про HighLoad?
В будущем:) Благодарю)!
Спасибо большое за ваш труд
Ждем полный курс🎉
Благодарю)!
Добрый день!
Очень толковые видео.
Я знаю, что на канале есть видео про docker, но хотелось бы глубже капнуть, с полноценной базой (не лайт), как вести разработку на локалке (например открыть проект в phpstorm и, чтобы он крутился на docker (я xampp сейчас пользуюсь), возможно даже установка на прод.
Как-то не вся картинка в голове сложилась. Может, конечно, это только у меня)
В будущем:)
согласен, за микросервисы надо браться когда в проекте уже десятки людей чтобы поделить их на отдельные независимые команды.
Дядя, хорош. Давай ещё. Ням ням
Благодарю)!
очень доступным языком объясняешь. Лучший программист на пхп на русскоязычном пространстве
Благодарю!)
Спасибо вам огромное!! Очень понятно и полезно!
Интересно послушать про Symfony в сравнении с Laravel если у вас был опыт его использования. Кст для микросервисов он думаю больше подходит относительно ларавеля.
Может в будущем:) Благодарю)!
Ждем продолжение!
Благодарю!)
Reddis и rabbitmq
Уже:)
просто лучший, по другому сказать не могу. Можно, пожалуйста, про HighLoad видео?
В будущем:) Благодарю)!
Ого круто🔥🔥🔥🔥
Благодарю)!
очень и очень годно, спасибо большое
По поводу SCALING, то, что вы сказали это не совсем то. SCALING подразумевает, что вы можете запустить несколько экземпляров одного и того же микросервиса, причем, даже не обязательно, что они будут запущены на одной и той же физической машине. Соответственно это одно из требований к стилю написания микросервиса, если сервис хранит, что-то важное в своей памяти, то это за микросервис считать нельзя, по этому бы критерию я и делил монолитные сервисы и микросервисы.
Благодарю)!
Интересно ещё научиться делать какие-то свои пакеты в композиции и их подключать в своих проектах. Ну например какие-то хелперы сделать и в свой гит залить. А потом в свой проект этот репозиторий подключать и юзать. Вот это интересно и полезно
cпасибо, что бы мы делали бы без вас, ждем курсы по реакт, JS, nest.js
Благодарю)!
очень полезное видео! 👍
Благодарю!:)
Как же замечательно что проходит мода на эти микросервисы.. Некоторые доходят до абсурда, делают 1 сервис для 1й функции, бьют в грудь мол это быстрее, легче обслуживать и тд.
Я конечно специально не искал, но... Первое нормальное объяснение по делу. Автор, обнял подкинул тебя, от души прям!
Ну не знаю, твой пример конечно дичь, но учитывая сколько времени существует эта концепция и насколько она не проработана, даже такой вариант не так уж плох. Мы с товарищем хотели сделать микросервисный пэт, первым делом столкнулись с сотнями архитектур, казалось бы, столько времени прошло, а до сих пор столько говна
Благодарю)!
Продолжай в том же духе! Круто
Будет ли в обозримом будущем разбор правильной (в рамках твоего опыта) архитектуры по работе с банковскими операциями?
Очень хороший вопрос
Поддерживаю! Хотелось бы увидеть видео на данную тему.
Понятие банковская операция имеет очень широкий смысл, что именно интересует?:)
@@laravelcreative Оплаты, формирование чеков, вебхуки и тд.
Понятно, что у каждого банка свои правила, но на стороне сайта +- должна быть одинаковая архитектура. (мб нет и я ошибаюсь, поэтому и прошу рассказать).
UPD: как минимум такие фичи, как та, что сумму переводят в копейки, чтобы при математических операциях не потерялись знаки после запятой, потому что php не очень точный на них. А потом возвращают обратно к рублям.
Огромный +!!!спасибо Вам!
Благодарю)!
покажи как делать микросервисные монолиты на практике ) как там jwt pasport sanctum в микросервисах использовать непонятно
Спасибо за ролик👍
Благодарю)!
Пример бы сервиса авторизации
То что нужно
Благодарю)!
покажешь как микромонолиты делать?
По плюса у монолита:
1. Высокая производительность, чего? Информационной системы, то нет, монолит в сравнении с сервисным подходом не обладает высокой производительностью, ибо подключение ко всем возможным происходит там.
2. Быстрый старт - ок.
3. Лёгкая поддержка. Под очень большим вопросом, особенно если, ломается, что-то в монолите он перестает весь работать.
4. Интеграция сотрудников в сравнении с микросервисами сложнее.
5. Ошибку найти в простом легче, чем в сложном. Если микросервис простой как пробка в нем и ошибок то особо быть не может.
6. CI/CD вопрос docker а не вопрос монолита или микросервиса.
А вы точно имели практику и дело с микро сервисной архитектурой?:) Я бы с вами согласился, правда практический опыт не позволяет такую роскошь.
@@laravelcreative ага практики с микросервисами больше 5 лет, а с монолитами около 8 лет, до изучения docker docker-swarm и k8s, делал только монолиты. Теперь на любой монолитный сервис смотрю, как на кусок больших и потенциальных проблем.
Понятно. Речь про производительность - это про подзапросы, которые увеличивают в целом время ответа. Монолит не делает подзапросы. Остальные пункты - в видео был акцент, что когда монолит разрастается, то его преимущества с повышением хаоса теряются. Вопрос ci/cd обычно всегда выставляется, как один из основных аргументов для перехода в микросервисы. Для видео использовал не только свой опыт, но и сделал выборку других специалистов. У вас видимо по другому, чему я конечно рад.
@@laravelcreative я вас не упрекаю, не в коем случае, не в компетенции, я выражаю своё мнения и только, исходя исключительно из своего опыта.
Но про производительность, я так и не понял вашу позицию. О каких подзапросах идет речь?
Спасибо) В данном случае имеется ввиду подзапросы от сервиса к сервису:) Понятно, что производительность можно в более широком смысле понимать.
го еще !
3:50 вы кажется немного сами не понимаете что такое микросервис что такое монолоит.
Слова состоит из монолитов вообще настораживает.
Картинки от одного блогера переходят к другому....только в фотошоп цвета меняют.
🔥
Благодарю)!
давай еще больше про фильтры раскажи а то ты 1 урок там расказал более налядный пример бы
по микросервисам интересно
Благодарю!:)
Привет! Спасибо! Круто было бы курс сделать по RabbitMq. Даже премиум записать. Много, кто купил бы, учитывая твою подачу материала.
Уже:)
@@laravelcreative , спасибо за труд. Я пока видео ждал, микросервис на ребите написал (Ларка/ Ларка). Но курс крайне необходимый, особенно в современных реалиях и требованиях к вакансиям.
Почему нельзя сделать голосовалку с возможными темами и сразу делать то, что желает большинство?
Можно:)
вопрос к автору- изучали ли вы фреймворк Yii2, довелось ли на нем работать, его преимущества/недостатки по сравнению с ларавел, стоит ли его учить?
не стоит. Там нет будущего
@@orangecoder3416 почему вы так считаете?
@@alexandr9900 этот фреймворк предназначен чтобы отдать заказы быстро сделав тяп ляп. Нормального ООП, соблюдение паттернов нету. Для более серьёзных проектов используются Symfony, Laravel.
Хочешь по нему курс?:)
@@laravelcreative да, многие разработчики сейчас работают на Yii2, а обучающих материалов по нему не так много, и они как правило 3-5 летней давности.
Ну да, микросервисы не увеличивают производительность, а сам факт того, что если большому количеству пользователей нужен один функционал, мы можем не иницализировать работу всего остального кода? А ещё тот факт, если будет большая нагрузка например на микросервис чатов, мы можем отдельно отмасштарбировать отдельно его а не всю платформу?
Девопс магия:)
5:15. Человек рассказывает о том, что распределение информационной системы не влияет на производительность 🤦
Как микросервисная архитектура может снижать производительность системы? Если она на РЕСТе, то контроллеры просто работают асинхронно. Если же на очередях - RabbitMQ или Kafka спасут мир, правда? А система разгрузится за счёт того, что один запрос никогда не будет проходить через все серверы. В худшем случае через 2-3 (за исключением фронтенда и БД), но это не так долго, правда?
Если шла речь о снижении производительности для пользователя... ну извините, но это незаметно. А вот в случае с монолитом при увеличении количества пользователей... Не буду продолжать