Ну вот есть у нас сервер на expressjs. Есть схемы на joi. Хочешь протестировать схемы? Довольно просто при помощи юнит тестов.
Но мы обычно просто пишем интеграционные тесты. Supertest + nock делают свою работу.
Была попытка внедрить написание контракт тестов, но никто так и не понял зачем еще раз писать какие-то тесты когда ты получаешь тоже самое out the box при написании интеграционных тестов (я имею ввиду на уровне ендпоинтов).
Мы сразу отказались от Jest на бэкенде когда фронтендисты начали его тащить к нам. Слишком много магии, слишком много открытых issues на гите. А еще он весело проглатывал ошибки...
Никто так и не смог нам объяснить зачем оно нам надо на бэкенде. А доводы типа ну это же крутой фреймворк от фейсбука нас не устроил.
Mocha + sinon + nock + chai + supertest закрывает буквально все потребности.
Жесть конечно. Даже не представляю где человеку который этим занимается будет не скучно работать... апишки там пилить с микросервисами, с браузером бадаться =))
Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.
Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.
Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?
struct StatusField {
originaldata string
newdata string
isModified }
Особенно если апишка частично crudish... И все ради того что бы иметь один метод reservationRepo.save(reservation);
Пользуем миро для евент сторминга, описания архитектурных решений и коммуникаций между сервисами, описания всяких флоу и т.д. В рилтайме можно обсудить и подправить. Удобно.
Меня смутило то что кафка стримс инстанс будет скачивать весь топик и строить таблицу в пямяти. А если у меня очень очень много данных? Например заказы с десятков или сотен магазинов. Как делается холодный старт? Что произойдет при рестарте инстансов? Или при стандартном скейл ап/даун?
Ох как хочу посмотреть через пару лет на их кодовую базу без стандартных абстракций когда их же менеджеры не дадут им время на рефакторинг что бы внедрить их в будущем.
Понятно что абстрактную фабрику не нужно пихать на каждый чих, но какие претензии к репозитори/дао слою? Возврат к спагетти, который ни тестировать ни рефакторить нормально нельзя...
Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.
Сразу в любом проекте будет понятно из чего он состоит и куда смотреть в случае чего.
Я так представляю в скором времени у них что бы понять что тут в сервисе происходит нужно будет читать тысячи строк, вместо того что бы пройтись беглым взглядом по абстракциям и файликам.
Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Если это b2b то есть смысл регистрацию и вход делать отдельным приложением и просто редиректить на него. Хочешь микро-фронт, хочешь вообще отдельное приложение написанное на другом стеке тупо под любым веб-сервером.
А если зарегаться может любой то смысла большого нет. Всегда можно зарегаться и увидеть все приложение.
А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.
Рассказали обо всем кроме самой информации об автоматизации. Как оно работает? Какие инструменты используются? Кто решает, стала ли проблема блокером или можно продолжать спать?
Смотрю на наши проблемы в продакшене, и они настолько разные, что человеку тяжело понять что вообще пострадало в результате, и что теперь делать.
Мне 35 и глядя на уровень нынешних выпускников всяких курсов и даже выходцев университетов, мне работы хватит лет до 100...
Причем владельцы стартапов стареют вместе с нами, и также понимают что опыт это очень ценный актив. Поэтому пора перестать плакать а том что карьера программиста заканчивается в 30...
Я не очень понимаю для чего все это.
Ну вот есть у нас сервер на expressjs. Есть схемы на joi. Хочешь протестировать схемы? Довольно просто при помощи юнит тестов.
Но мы обычно просто пишем интеграционные тесты. Supertest + nock делают свою работу.
Была попытка внедрить написание контракт тестов, но никто так и не понял зачем еще раз писать какие-то тесты когда ты получаешь тоже самое out the box при написании интеграционных тестов (я имею ввиду на уровне ендпоинтов).
Мы сразу отказались от Jest на бэкенде когда фронтендисты начали его тащить к нам. Слишком много магии, слишком много открытых issues на гите. А еще он весело проглатывал ошибки...
Никто так и не смог нам объяснить зачем оно нам надо на бэкенде. А доводы типа ну это же крутой фреймворк от фейсбука нас не устроил.
Mocha + sinon + nock + chai + supertest закрывает буквально все потребности.
И в том же Google Meet в хроме...
Когда спрашивают дать ETA основываясь на названии таска ?
Рассматривали ли вы облачные решения, как например snowflake?
Эта статья это стеб?
Не дай бог после таких советов студенты теперь все вычисления будут в конструктор пихать ?
А кто реально видел что бы кто-то использовал эти настройки на живой базе в продакшене ? Я вот не видел :/ А хотелось бы...
Я очень люблю табличные тесты когда не мне их отлаживать в случае поломки. Потому что это ад.
Прикольно, должно экономить время и количество букв в файле. На деле, лишь добавляет логики, усложняет дебаг.
Ну иногда не особа есть выбор. Например когда очень жесткое требование на Exactly once delivery.
Если я не ошибаюсь, решение этой проблемы это хранить оффсеты на стороне консюмера. Что то вроде Outbox Pattern только на входящие сообщения.
Kafka Consumer starts
Load the last offset from the db
Receive message from kafka
tr = Start db transaction
handleMessage(tr)
persistOffset(tr)
tr.commit()
Или все или ничего...
Жесть конечно. Даже не представляю где человеку который этим занимается будет не скучно работать... апишки там пилить с микросервисами, с браузером бадаться =))
Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.
Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.
Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?
struct StatusField {originaldata stringnewdata stringisModified}
Особенно если апишка частично crudish...
И все ради того что бы иметь один метод reservationRepo.save(reservation);
Будет интересно посмотреть на ваше решение.
В закладки. Интересно поиграться.
Мы для эмуляции pub/sub делали эксченжи и присоединяли кьюшки что бы каждая получала копию сообщений. Работает оно, но кьюшки плодятся, мейнтенс...
Стримы интересно выглядят... надо только раббит обновить.
Но в конце концов мы в большинстве флоу переходим на кафку. Все таки partial order of messages и авто ассайн воркеров к партишинам для нас маст хэв.
Пользуем миро для евент сторминга, описания архитектурных решений и коммуникаций между сервисами, описания всяких флоу и т.д. В рилтайме можно обсудить и подправить. Удобно.
Меня смутило то что кафка стримс инстанс будет скачивать весь топик и строить таблицу в пямяти. А если у меня очень очень много данных? Например заказы с десятков или сотен магазинов. Как делается холодный старт? Что произойдет при рестарте инстансов? Или при стандартном скейл ап/даун?
Или я что-то не понял?
Ох как хочу посмотреть через пару лет на их кодовую базу без стандартных абстракций когда их же менеджеры не дадут им время на рефакторинг что бы внедрить их в будущем.
Понятно что абстрактную фабрику не нужно пихать на каждый чих, но какие претензии к репозитори/дао слою? Возврат к спагетти, который ни тестировать ни рефакторить нормально нельзя...
Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.
Сразу в любом проекте будет понятно из чего он состоит и куда смотреть в случае чего.
Я так представляю в скором времени у них что бы понять что тут в сервисе происходит нужно будет читать тысячи строк, вместо того что бы пройтись беглым взглядом по абстракциям и файликам.
Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Если это b2b то есть смысл регистрацию и вход делать отдельным приложением и просто редиректить на него. Хочешь микро-фронт, хочешь вообще отдельное приложение написанное на другом стеке тупо под любым веб-сервером.
А если зарегаться может любой то смысла большого нет. Всегда можно зарегаться и увидеть все приложение.
А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.
Рассказали обо всем кроме самой информации об автоматизации. Как оно работает? Какие инструменты используются? Кто решает, стала ли проблема блокером или можно продолжать спать?
Смотрю на наши проблемы в продакшене, и они настолько разные, что человеку тяжело понять что вообще пострадало в результате, и что теперь делать.
Мне 35 и глядя на уровень нынешних выпускников всяких курсов и даже выходцев университетов, мне работы хватит лет до 100...
Причем владельцы стартапов стареют вместе с нами, и также понимают что опыт это очень ценный актив. Поэтому пора перестать плакать а том что карьера программиста заканчивается в 30...