Как мы избавились от 80% своего кода, повысив скорость разработки и уменьшив количество ошибок

Т.е. контракт может использовать только абстрактный класс?

Может EntityManagerInterface создан потому что EntityManager можно задекорировать?

Как мы избавились от 80% своего кода, повысив скорость разработки и уменьшив количество ошибок

Это все верно только для микросервисов.

Для средних сервисов это - копипаст и лапшекод. Да, плохая абстракция хуже копипаста, но если она грамотная это ок, даже если можно и без нее.

Много классов, мало классов, это такое себе мерило. Я видел обратную сторону, написали в 10 строчек сервис, и потом заюзали его в 100 местах. А потом поняли, что получился бетон.

Осознанный нейминг + четкие границы контекстов + нормальная модульность

Fast Reverse Proxy как альтернатива Ngrok

да, вариант, мне правда не нравится, т.к. он не так красиво ложится на связку с докером, + "числовые" домены тоже не очень понятны.

я так понял, вы предлагаете такую схему
{PORT}.dev{X}.example.com -> 10.0.0.X:PORT
какой проект, какой дев, не ясно.
+ тут с wildcard сертификатами сложнее становится

мне лучше понимать когда такой тип домена
cms-vasiliy.example.com
api-cms-vasily.example.com

Fast Reverse Proxy как альтернатива Ngrok

да, писатель из меня еще тот)

да и не заметил что в 1 спойлер засунул два других, только сейчас понял, поправил. + дописал этот момент

Fast Reverse Proxy как альтернатива Ngrok

Смотрите...

1. proxy frp находится в связке контейнеров. Поднимая проект (docker-compose up) поднимаешь все сразу: тунель, nginx, php, sql. после того как поработал, сделал docker-compose down и убил и прокси и nginx и тд.

2. ненужно править nginx серверный, в той статье что вы поделились, проксирование на 10.99.0.2:8443; это совсем не гибко, пока ты один и у тебя всегда проект будет на 8443 то пойдет, но так не бывает, в моей реальности :)

3. открывать порты nginx (docker) ненужно, все проксируется внутри сети докер-проекта. Т.е. вообще нет открытых портов

4. я не писал, но у FRP можно создать любой тунель по tcp, ssh, + куча плагинов есть

5. самое главное, настройка не на сервере происходит, а на клиенте. На клиенте указываешь какой хост юзаешь, в какой контейнер проксируешь, на какой порт, какой тип проксирования.

В статье не писал, все это в репе есть, настройка на клиенте (внутри докер контейнера) proxy

client.ini

[common]
server_addr = {SERVER_HOST}
server_port = {SERVER_PORT}
token = {SERVER_TOKEN}
login_fail_exit = true

[frontend-{PERSONAL_ALIAS}]
type = http
local_ip = webserver
local_port = 8081
subdomain = {PERSONAL_ALIAS}

[admin-{PERSONAL_ALIAS}]
type = http
local_ip = webserver
local_port = 8082
subdomain = admin-{PERSONAL_ALIAS}

[api-{PERSONAL_ALIAS}]
type = http
local_ip = webserver
local_port = 8083
subdomain = api-{PERSONAL_ALIAS}

и dockre-compose воображаемого проекта, в реальный проект перенести нужно только блок proxy и подсунуть ему нужные конфиги, см. выше

Клиентский docker-compose.yml

version: '3.7'

services:

  proxy:
    build: docker/proxy
    depends_on:
      - webserver
    environment:
      PERSONAL_ALIAS: ${REVERSE_PROXY_PERSONAL_ALIAS}
      SERVER_HOST: ${REVERSE_PROXY_SERVER_HOST}
      SERVER_TOKEN: ${REVERSE_PROXY_SERVER_TOKEN}
      SERVER_PORT: ${REVERSE_PROXY_SERVER_PORT}

  webserver:
    image: nginx:alpine
    restart: unless-stopped
    volumes:
      - ./docker/nginx/templates:/etc/nginx/templates
    depends_on:
      - app

  app:
    image: php:8-fpm-alpine
    restart: unless-stopped
    volumes:
      - ./src:/var/www/html

Fast Reverse Proxy как альтернатива Ngrok

Возможно я не раскрыл мысль.

Допустим у вас есть сервер, на нем Nginx + VPN. У вас два разработчика в команде. Вы решили, что

• *.dev1.example.com будет проксировать запрос на 10.0.0.1

• *.dev2.example.com будет проксировать запрос на 10.0.0.2

Когда придет новый дев, нужно будет в конфиге Nginx правки вносить. Не проблема, но зачем? если с FRP управление какой поддомен куда вести будет уходит на плечи клиента.

Хорошо, будем руками править на reverse nginx, но дальше, все запросы для dev1 идут на 10.0.0.1, у меня развернуто 2 проекта, допустим:

• site, admin-site, static-site, api-site - это 1 docker-compose

• site2, admin-site2, static-site2, api-site2 - это 2 docker-compose

теперь стоит задача, создать маршруты локально,

• site.dev1.example.com -> 10.0.0.1 -> docker container site

• site-admin.dev1.example.com -> 10.0.0.1 -> docker container site-admin

• ....

когда разработка идет в докере, обычно это делаю так

version: '3.7'

services:
  webserver:
    image: nginx:alpine
    depends_on:
      - app
  app:
    image: php:8-fpm-alpine

Вы будете на клиенте в не докера еще 1 nginx ставить который будет роутить запросы? или на сервере будете указывать порты? которые откроете в докере?

И снова.... технически решаемо, но это ад становится с поддержкой.

С FRP всего этого геморроя нет.

Ngrok, кстати, на такой услуге зарабатывает, FRP 40т звезд на гитхабе, это как минимум намек на то что инструмент востребованный.

Могу предположить что вы ближе к администрированию, тогда вам возможно сложно понять понять взгляд программиста.

Fast Reverse Proxy как альтернатива Ngrok

Это уже как минимум не проще.

А добавьте сюда вопросы менеджмента роутинга. Например появился новый дев, и теперь ему нужно тоже проксировать, добавлять правила в nginx?

И дальше, как локально роутить трафик по контейнерам? У нас докер, одновременно может работать несколько nginx

Да, технически это возможно. Но это совсем не проще. ИМХО.

Но если быть откровенным, такая мысль не приходила, возможно ее так же можно до ума довести. Спасибо

Fast Reverse Proxy как альтернатива Ngrok

Ну опишите, что для этого нужно сделать. По шагам.

Fast Reverse Proxy как альтернатива Ngrok

Когда запрос, к примеру от банка, прилетает к вам. Которым он уведомляет, что транзакция которую вы создали ранее, завершена успешно (или нет)

Fast Reverse Proxy как альтернатива Ngrok

Как вы собрались проксировать запрос с nginx в локальную сеть?

Fast Reverse Proxy как альтернатива Ngrok

1. получить callback от внешнего сервиса

2. посмотреть на приложение со смартфона

3. поделится ссылкой с коллегой для обсуждения

4. https не самоподписной

5. много причин можно найти

но не всем это нужно, мне долгое время так же ненужно было

23 минуты. Оправдание тугодумов

Может быть так, а может быть нет. Не буду утверждать :)
Время покажет, а может и не покажет :)

23 минуты. Оправдание тугодумов

эта статья, сработала для меня, как сеанс терапии :)
Становясь старше, я стал замечать, что мои утверждения часто бывают ложными или требующие корректировки. Когда я это осознал, утверждать стал меньше, тоже слушаю молча. Но смотря на окружающих стали появляться комплексы. Впрочем я объяснял себе это, но когда читаешь что это ок, немного легче :)

Symfony CLI — новый инструмент для локальной разработки

Без поддержки докера, ценность данной фичи сомнительна

Книга «Экстремальное программирование: разработка через тестирование»

Прочел. Отличная книга. Для меня она больше была про стресс в разработке. Почему он приходит и что с этим делать. Так же что TDD это не про тесты, это про разработку.

Что стоит за чистотой в вашей квартире, или препарация Qlean

Сколько гневных комментов… Ничего плохого в разделении на сервисы при такой не большой посещаемости нет. И то что два человека на сервис, в этом тоже есть свои плюсы. С узкой ответственностью можно глубже «нырнуть». Если процесс коммуникации хороший, то вероятно качество каждого сервиса будет выше и системы в целом выше.

Горе от ума, или Почему отличники пишут непонятный код

Очень согласен с автором. Код мы должны писать для людей, хоть и использует его машина. Весь мир сейчас движется к упрощению подачи информации, особенно это хорошо знают маркетологи, которые понимают, что чем сложнее и продукт заходит в голову клиента, тем меньше конверсия!!! Ведь так же и с кодом. Если бы программист который получает легаси имел бы выбор, чаще он бы отказался ковыряться в говнокоде, где методы-контроллеры на 500 строк. И на языке маркетолога, это потерянный клиент.

Загоним мамонта в яму: как провести презентацию, чтобы вас услышали и запомнили

Спасибо!
Интересно как сработало видео с Гейтсом…
Начал смореть,
Вижу 20 мин…
Да ну… не хочу…
прочел что цепляет с с 4 минуты, посмотрел…
досмотрел до конца))

Как программисты-самоучки в реальности получают работу

Так кого же и с кем вы сравниваете? И как?

Я наблюдаю за кандидатами в нашу компанию. И это заметно.

О, уже «большинство» вместо «никому не научиться». Об этом и речь.

Да, конечно, «никому» — не значит 100% никто. Всегда есть ислючения. Но это значит что 99% будут «маэстро».

Почему? Вы в курсе, что системные теоретические знания в музыкальном образовании дают (в советской/русской школе) не раньше училища?

И что?

Как программисты-самоучки в реальности получают работу

В любой области?

Я о программировании, с музыкой немного по другому. Но есть параллели.

Это если конкретно про Гарвард говорить.

Речь о хорошем универе

Речь идет о том, что вы утверждаете, что самообразование, фактически, невозможно.

Я утверждаю что для большенства самообразование не даст системных знаний. И почти всегда это похоже будет на дворогого гитариста, который знает 3 аккорда и называет себя маестро.

И да, никто из перечисленных мной музыкантов (и композиторов) образования уровня Гарварда

В этом смысле сранивать музыку и точные науки не правильно