Заглядывайте в описание, там я оставил очень много хороших и бесплатных материалов для построения архитекутры В следующих видосах мы создадим REST/БД архитектуру (в теории они выйдут быстрее чем это видео :З)
Спасибо за твой разбор модульного монолита! Видно, что проделана большая и серьезная работа. Хочется добавить, что переезд на микросервисы вполне возможен и без использования ивентов. Достаточно превратить "контракты" в API. А вот с чем почти гарантировано возникнут проблемы при переезде на микросервисы, так это с распределенными транзакциями.
Большое спасибо, такие комментарии очень мотивируют снимать дальше :) Полностью согласен с тобой, отличное дополнение про переезд на микросервисы P.S. Если интересно можешь еще про REST API глянуть, интересно будет послушать твое мнение там, ибо видно, что ты человек с опытом :)
Большое спасибо за ожидание, очень стараюсь сильно не затягивать и делать всё качественно :) > и уже думал запросил проект) Очень надеюсь что не заброшу, ибо самому интересно ;)
По поводу курса, все звучит очень круто и туториалов с подобной детализацией практически нет, но есть огромное НО. Небольшие ролики по 15мин выходят раз в месяц и по итогу прошло три месяца(идет уже 4), а мы только послушали какой у нас план.
Всё так, к сожалению времени просто не хватает :( Жертвовать качеством ради скорости не хочу, хотелось бы всё проработать детально Если что я работаю над курсом, не сижу сложа руки, помню, что меня ждут и стараюсь не задерживаться Прошу прощения за такие паузы.
отличная идея проекта. топ! по мне, на улучшение: - использовать каскадное удаление. зачем доп зависимости и вызовы, если база одна. - поменять завимиости Discussion и Offer от Reputation, а Reputation от Profile.
> отличная идея проекта. топ! Спасибо!) > использовать каскадное удаление. зачем доп зависимости и вызовы, если база одна. Да, так тоже можно, и, наверное, лучше, но мне нравится подход когда мы контролируем логику в коде, а не в базе, т.к. помимо удаления у нас могут появится сторонние вызовы. Например если мы захотим удалить картинку у профиля, то нам нужно будет вызвать удаление в базе и удаление в файловой системе там где мы храним эту фотографию физически, а если у нас будет каскад, то удалить в системе можно забыть, хотя тут всё зависит от ситуации и тема спорная. В любом случае спасибо, подумаю над каскадом побольше :) > поменять завимиости Discussion и Offer от Reputation Дискуссия и оффер вроде бы не зависит от репутации, т.е. если мы захотим нарисовать на фронтенде дискуссию + репутацию к этой дискуссии, то мы вызовем 2 метода Но при этом репутация зависит от дискуссии, т.к. если дискуссии не будет, то и повышать нечего (вроде бы ничего не напутал, поправь меня если что) > а Reputation от Profile Да, тут нужно не поменять, а добавить зависимость, т.к. если удалять профиль, то нужно вызвать метод удаления репутации (это если делать без каскада) Но зависимости все примерные и не очень полные, если бы я всё нарисовал как есть, то их бы было куда больше и куда запутаннее, так что я решил убрать лишнее и оставить только явно нужные зависимости Еще раз спасибо за ценный коммент! :)
Еще бы дополнил себя, что если захочется переехать на разные БД + микросервисы, то каскад помешает нам это сделать удобно (но в нашем случае это не так, т.к. я не планирую этого делать)
@@kurnakovv интересно будем посмотреть на схему бд поближе, как сделаешь) я вижу репутацию как очень независимую сущность. если к примеру, учитель захочет добавить сертификат, то это может, условно, повысить репутацию. т.е. всегда есть, что повышать, если масшабировать систему ;)
@@vladhr4083 Кстати да, хороший кейс, учту)) Про схему в БД будет отдельный ролик (след про REST, а после про БД), буду очень рад послушать твое мнение если посмотришь потом :)
Заглядывайте в описание, там я оставил очень много хороших и бесплатных материалов для построения архитекутры
В следующих видосах мы создадим REST/БД архитектуру (в теории они выйдут быстрее чем это видео :З)
Спасибо за твой разбор модульного монолита! Видно, что проделана большая и серьезная работа.
Хочется добавить, что переезд на микросервисы вполне возможен и без использования ивентов. Достаточно превратить "контракты" в API.
А вот с чем почти гарантировано возникнут проблемы при переезде на микросервисы, так это с распределенными транзакциями.
Большое спасибо, такие комментарии очень мотивируют снимать дальше :)
Полностью согласен с тобой, отличное дополнение про переезд на микросервисы
P.S. Если интересно можешь еще про REST API глянуть, интересно будет послушать твое мнение там, ибо видно, что ты человек с опытом :)
Очень классно получилось! Спасибо за видео, ждем продолжение.
Спасибо большое! Рад слышать что понравилось :)
Спасибо огромное за видео! Я очень его ждал и уже думал запросил проект)
Большое спасибо за ожидание, очень стараюсь сильно не затягивать и делать всё качественно :)
> и уже думал запросил проект)
Очень надеюсь что не заброшу, ибо самому интересно ;)
Спасибо за видео за ваше труд и за объяснение инфо❤👍🙏💯🎯
Всегда пожалуйста, рад что понравилось! :)
По поводу курса, все звучит очень круто и туториалов с подобной детализацией практически нет, но есть огромное НО. Небольшие ролики по 15мин выходят раз в месяц и по итогу прошло три месяца(идет уже 4), а мы только послушали какой у нас план.
Всё так, к сожалению времени просто не хватает :(
Жертвовать качеством ради скорости не хочу, хотелось бы всё проработать детально
Если что я работаю над курсом, не сижу сложа руки, помню, что меня ждут и стараюсь не задерживаться
Прошу прощения за такие паузы.
отличная идея проекта. топ!
по мне, на улучшение:
- использовать каскадное удаление. зачем доп зависимости и вызовы, если база одна.
- поменять завимиости Discussion и Offer от Reputation, а Reputation от Profile.
> отличная идея проекта. топ!
Спасибо!)
> использовать каскадное удаление. зачем доп зависимости и вызовы, если база одна.
Да, так тоже можно, и, наверное, лучше, но мне нравится подход когда мы контролируем логику в коде, а не в базе, т.к. помимо удаления у нас могут появится сторонние вызовы. Например если мы захотим удалить картинку у профиля, то нам нужно будет вызвать удаление в базе и удаление в файловой системе там где мы храним эту фотографию физически, а если у нас будет каскад, то удалить в системе можно забыть, хотя тут всё зависит от ситуации и тема спорная. В любом случае спасибо, подумаю над каскадом побольше :)
> поменять завимиости Discussion и Offer от Reputation
Дискуссия и оффер вроде бы не зависит от репутации, т.е. если мы захотим нарисовать на фронтенде дискуссию + репутацию к этой дискуссии, то мы вызовем 2 метода
Но при этом репутация зависит от дискуссии, т.к. если дискуссии не будет, то и повышать нечего (вроде бы ничего не напутал, поправь меня если что)
> а Reputation от Profile
Да, тут нужно не поменять, а добавить зависимость, т.к. если удалять профиль, то нужно вызвать метод удаления репутации (это если делать без каскада)
Но зависимости все примерные и не очень полные, если бы я всё нарисовал как есть, то их бы было куда больше и куда запутаннее, так что я решил убрать лишнее и оставить только явно нужные зависимости
Еще раз спасибо за ценный коммент! :)
Еще бы дополнил себя, что если захочется переехать на разные БД + микросервисы, то каскад помешает нам это сделать удобно (но в нашем случае это не так, т.к. я не планирую этого делать)
@@kurnakovv интересно будем посмотреть на схему бд поближе, как сделаешь) я вижу репутацию как очень независимую сущность. если к примеру, учитель захочет добавить сертификат, то это может, условно, повысить репутацию. т.е. всегда есть, что повышать, если масшабировать систему ;)
@@vladhr4083 Кстати да, хороший кейс, учту)) Про схему в БД будет отдельный ролик (след про REST, а после про БД), буду очень рад послушать твое мнение если посмотришь потом :)
Зачем озвучивать нейросетями?