Если вашем мире серверные приложения в талицы не ходят и вообще только с хранимками общаются, то сложно вам будет объяснить проблемы, когда не одно, а несколько приложений ходят в базу и выполняют там напрямую UPDATE запросы. Хотя обвешаться хранимками, запретив прямой доступ к таблицам всем, и выставить микросервис — решения для одной и той же проблемы, по сути. Просто разные решения. Одним проектам подходит одни, другим — другие. В том числе и смотря какие люди работают на проекте. Я вот уйду с любого проекта как только там решат ключевую логику переносить в хранимки.
P.S. Транзакционность по http нормально делать: один запрос — одна транзакция. Как каждый вызов хранимки в транзакцию обернуть. Да и не говорил я про http.
P.P.S. Микро я везде в скобках ставил, чтобы подчеркнуть что оно не принципиально, а вы с ним так...
(Микро)сервис, который монополизирует работу с базой, в которую сейчас стучится несколько приложений, и хорошо если только одно на запись.
Чтобы трём приложениям сделать запросы в БД им всем нужно знать схему/ Иными словами, изменения в схеме нужно дублировать в коде всех приложений. Спрятав базу за сервисом (сделанным с нуля или преобразованным из одного из приложений) мы избавляемся от этого — минорные изменения схемы не повлияют на публичный API сервиса.
Рассказывает фреймворку какой метод какого контроллера дернуть, когда придёт GET запрос /ru/register и как сформировать урл для роута с именем register
Аннотации/атрибуты и задаются на уровне контроллера. Есть, правда, минус — поиском по исходникам сложно понять какой контроллер за обработку конкретного урла отвечает. Ну и формально нарушается SRP — контроллер должен знать что-то о роутах, на которые он должен откликаться, управлять конфигурацией фреймворка по сути
Вроде как нет. Санкции — это и меры, применяемые к нарушителю законов, правил, договоров, и разрешения — есть ещё глагол "санкционировать" именно в значении "разрешить", "одобрить".
А чем техлиды у вас занимаются? Как по мне, многие разработчики идут в тимлиды, лишь потому что позиций чистых техлидов мало, а тимлид чаще всего — это техлид+часть обязанностей ПМ в нагрузку. Вот и идут в тимлиды, чтобы хоть часть времени быть техлидом. Сам такой.
Статический анализ кода многие считают must have в php.
И по ощущениям это совсем другие гигабайты
А он должен сообщать об этом при трудоустройстве?
Если вашем мире серверные приложения в талицы не ходят и вообще только с хранимками общаются, то сложно вам будет объяснить проблемы, когда не одно, а несколько приложений ходят в базу и выполняют там напрямую UPDATE запросы. Хотя обвешаться хранимками, запретив прямой доступ к таблицам всем, и выставить микросервис — решения для одной и той же проблемы, по сути. Просто разные решения. Одним проектам подходит одни, другим — другие. В том числе и смотря какие люди работают на проекте. Я вот уйду с любого проекта как только там решат ключевую логику переносить в хранимки.
P.S. Транзакционность по http нормально делать: один запрос — одна транзакция. Как каждый вызов хранимки в транзакцию обернуть. Да и не говорил я про http.
P.P.S. Микро я везде в скобках ставил, чтобы подчеркнуть что оно не принципиально, а вы с ним так...
Как-то всё про начинающих. А как дела обстоят, с теми кто приобрёл инвалидность уже будучи опытным разработчиком, например?
(Микро)сервис, который монополизирует работу с базой, в которую сейчас стучится несколько приложений, и хорошо если только одно на запись.
Чтобы трём приложениям сделать запросы в БД им всем нужно знать схему/ Иными словами, изменения в схеме нужно дублировать в коде всех приложений. Спрятав базу за сервисом (сделанным с нуля или преобразованным из одного из приложений) мы избавляемся от этого — минорные изменения схемы не повлияют на публичный API сервиса.
Можно пример глянуть?
Но по умолчанию скорее нужен чем нет. Отключая своа нужно чётко понимать зачем и как это может аукнуться.
Рассказывает фреймворку какой метод какого контроллера дернуть, когда придёт GET запрос /ru/register и как сформировать урл для роута с именем register
Аннотации/атрибуты и задаются на уровне контроллера. Есть, правда, минус — поиском по исходникам сложно понять какой контроллер за обработку конкретного урла отвечает. Ну и формально нарушается SRP — контроллер должен знать что-то о роутах, на которые он должен откликаться, управлять конфигурацией фреймворка по сути
А самовольное занятие какой-то роли — это точно карьерный рост?
(микро)сервис, владеющий базой.
Докер последний умеет в cgroups v2, подозреваю, что на самом деле это containerd умеет.
Только гибернация тогда не работает...
Вроде как нет. Санкции — это и меры, применяемые к нарушителю законов, правил, договоров, и разрешения — есть ещё глагол "санкционировать" именно в значении "разрешить", "одобрить".
Аналогичный кусок:
Ну вот же в карьерных возможностях пишите "можно стать техлидером" — это роль или позиция с бейджиком?
Санкций в русском тоже контроним? Санкция (разрешение) суда на обыск и Санкции (Запрет) на ввоз товаров
С десяти кратным резервном памяти чего бы не жить
А чем техлиды у вас занимаются? Как по мне, многие разработчики идут в тимлиды, лишь потому что позиций чистых техлидов мало, а тимлид чаще всего — это техлид+часть обязанностей ПМ в нагрузку. Вот и идут в тимлиды, чтобы хоть часть времени быть техлидом. Сам такой.
Кроме последнего пункта вы больше про техлида говорите, нет?