не думаю что ты меня понял)

а сейчас время от времени в частном чате возникают вопросы "почему не работает" )

ну, где без версионирования

ну, где без версионирования

"без версионирования" != "без мозгов"

там модели данных просто толстеют и толстеют а люди забывают ставить депрекейтед например на каких то параметрах

а версия не меняется. ни адреса, ни номинально

понятно что апи развивается но потом начались смешные правила типа "если указали А не указывайте Б потому что будет ошибка"

а версия не меняется. ни адреса, ни номинально

ну даже если ты не юзаешь версионирование - "какую-то" версию на которую расчитывает клиент тебе надо присылать. Тебе ж надо как-то знать все ли обновились и можно дропать совместимость.

но это даже близко не походит на варианты версионирования на урлах (ты думаю и сам понимаешь что это рак), и очень отдаленно напоминает вариант через content negotiation

это больше про процессы и то как ты работаешь с клиентами твоей API

типа та же штука что теги для билдов твоего приложения - это не влияет на то как ты код пишешь но для процесса это важно

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

и если тебе надо суппортить API в течении года - то и на уровне приложения обратную совместимость придется делать

p.s. штуки типа graphql позволяют вообще не заморачиваться ибо ты всегда знаешь какие клиенты что юзают, это решает вопрос "когда депрекейтед штуки можно удалить"

ты сам делал уже на грфе?

да, пока маленькую апишечку

там же наверное ппц геморой настраивать лимиты выборки

там же наверное ппц геморой настраивать лимиты выборки

да нет, не особо... расставил наугад косты (здравый смысл) и вуаля

для публичного API гемороя конечно больше, но похожие проблемы и с http api) только больше для клиента)

если клиенту ну вот надо достать кучу данных - он достанет, просто сделает N запросов

а с точки зрения секьюрити атаки отражать - это примерно одинаково сложно

в случае http api у тебя из вариантов рэйт лимит, а в graphql - стоимость подключения филда

а еще каждый из N запросов может быть по отдельности быстрее чем 1 общий на граф. клиент просто начнет какие то данные получать быстрее. понятно что все запросы дольше будут

> а еще каждый из N запросов может быть по отдельности быстрее быстрее конечно, но добавь к этому лэтенси (особенно мобильных сетей), даже http2 тебе тут не особо спасет

ну и если у тебя именно граф - то есть какие-то связанные вещи, все запросы паралельно послать не выйдет

и graphql начинает уже выигрывать)

правда на запись на graphql сделано как по мне убого но жить можно

ну и вообще graphql не надо воспринимать как "убийцу rest" - оно хорошо дополняет друг друга)

чуваки, прерву ваши возвышенные беседы о вечном

а не появилось какой нормальной альтернативы свифтмейлеру?

а не появилось какой нормальной альтернативы свифтмейлеру?

примерно такого же - нет (зачем такой же пилить?))

есть конечно PHPMailer но это то же самое примерно

многие просто переключаются потиху на всякие sendgrid-ы или mailgun-ы и шлют не через smtp а через апишки

а для smtp - лучше сэндгрида ниче нет

да, я тоже сильно за хттп вместо смтп

но тогда надо очереди свои городить

а поцфекс это все сам делает за тебя

знай шли себе в локалхост

но там смтп нужен =/

это как тебе удобно. Раньше юзал api blueprint (и до сих пор считаю этот формат крутым), сегодня рекомендую посмотреть в сторону raml (хотя блупринта может и хватить). Мне такой подход (сначала дока) был удобен потому что можно было распаралелить разработку клиента и сервера. Это часто нас спасало.

если можно, хотелось бы узнать твою точку зрения по поводу raml vs swagger) и с помощью чего генерируете код из raml Спасибо

Возьми nelmioapidoc и все будет хорошо

Возьми nelmioapidoc и все будет хорошо

или нет)

если можно, хотелось бы узнать твою точку зрения по поводу raml vs swagger) и с помощью чего генерируете код из raml Спасибо

с этим все плохо)

(у сваггера чуть лучше). Почти все кастомные лесапеды ищут (и почти всегда на ноде потому что расчитывать на нормальные тулы на php не приходится)

ага, интересовался такими штуками все тлен, разве писать под сваггер вручную (и под 3)

ага, интересовался такими штуками все тлен, разве писать под сваггер вручную (и под 3)

сваггер руками как-то вообще не ок

сваггер руками как-то вообще не ок

не нашёл нормального пока ну и без графкуэля, пока к нему не готов (нужно пощупать)

я же хотел интеграции с json schema а в неё умеет только третий сваггер а в него никто не умеет)

спасибо за ответы )

или нет)

та там все ок, там от nelmio парсинг роутинга, сущностей и форм. все остальное php swagger

та там все ок, там от nelmio парсинг роутинга, сущностей и форм. все остальное php swagger

я могу сказать так: - формы в апишках не нужны вообще - если у тебя модель данных в сущностях (по сути в базе) такая же как и в респонсах API - рассмотри вариант вообще ничего не писать а заюзать какой-нибудь гейтвей к базе

я могу сказать так: - формы в апишках не нужны вообще - если у тебя модель данных в сущностях (по сути в базе) такая же как и в респонсах API - рассмотри вариант вообще ничего не писать а заюзать какой-нибудь гейтвей к базе

там с учетом jms еще, то что ты любишь)

я не буду спорить, потому что оно все так)

сваггер руками как-то вообще не ок

На самом деле весьма ок, если в команде работают люди, которым не впадлу по человечески задокументировать реализованный ими функционал

Мы пишем все в yaml-файлах, обмазываемся рефами, дробим все на мелкие файлы, а на выходе получаетчя один скомпилированный json-файл

Смущает только скудная экосистема вокруг openapi 3. Даже банального валидатора доки найти не удалось, поэтому проебы замечаются лишь спустя какое-то время

Смущает только скудная экосистема вокруг openapi 3. Даже банального валидатора доки найти не удалось, поэтому проебы замечаются лишь спустя какое-то время

во, та же фигня формат хорош, но экосистемы йок

во, та же фигня формат хорош, но экосистемы йок

До формата тоже можно доклпаться. Например, там нельзя два разных респонса на один статус код повесить. Ухх. Приходится изголяться, делая ключи вида 400 (Validation Error) и 400 (Invalid JSON)

по крайней мере он мощнее иных

вдруг кого-то заинтересует: https://vaughnvernon.co/?p=942 The Ideal Domain-Driven Design Aggregate Store?

рельсы говно, симфони топчик

а как вам http://hanamirb.org/ ?

а как вам http://hanamirb.org/ ?

скучно

а как вам http://hanamirb.org/ ?

Не воспринимай это серьезно

ERROR: S client not available

Это была шутка скорее всего

http://symfony.com/blog/new-in-symfony-4-1-messenger-component

о, его уже прямо воткнули

неделю назад там был один коммит кажись)

крутяг

можно будет развернуть мессаджориентированную архитектуру )

Может кто помнит, был у меня косяк с доктриной и постгрес. Дифф генерировал лишние действия в миграции. (Типа приведение к datetimetz, то что и так TIMESTAMP(0) WITH TIME ZONE). Так вот я разобрался. Косяк связан с потерявшимися доктриноваскими комменитами вида (DC2Type:datetimetz). Вот такая вот херня... кто ж знал что доктрин юзает комменты, как мету к таблицам...

можно будет развернуть мессаджориентированную архитектуру )

и обмазаться микросервисами!

будет монолит на мессаджах

вместо иньекции сервисов в экшн, будем диспатчить мессаджи

дык есть евент диспетчер

это евенты

т.е. ты мог такое делать уже лет как 10)

https://github.com/php-enqueue/async-event-dispatcher

мессаджи это наоборот

и точно command bus поддерживает асинхронный диспатчинг команд

дык есть евент диспетчер

евенты - есть 1 евент и куча подписчисков мессаджы - есть 1 мессадж, который все вызывают

а если много ивентов и много мессаджей?)

и это все различие) в нескольких строках кода

может ивенты это в пределах одной системы, а мессаджи между разными системами, не?

ивенты можно тоже в бекграунд отправлять

и где-то там ларавел пробегал

ну мб эвент это мессадж который описывает кто его кинул (причина) и имеет какой то контекст

а мессадж это прост данные

+1

@spudro а чем не устраивает стандарный механизм подключения ExceptionHandler через конфиг? (через event'ы)

просто любопытно

@spudro а чем не устраивает стандарный механизм подключения ExceptionHandler через конфиг? (через event'ы)

через GetResponseForExceptionEvent?

kernel.exception

через kernel.exception, да

подключение ExceptionListener по сути то же самое, что и ExceptionHandler