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