Однако при загрузке/дампе очень больших последовательностей данных AXON выигрывает из-за того, что не нужно сначала строить всю последовательность в памяти.
В большинстве парсеров JSON-a используется потоковая обработка (по крайней мере в яве), так что этот выигрышь мимо кассы.
Раз для сериализации, то можно немного статистики по скорости сериализации/десериализации + средний объём данных в сравнении с JSON и MessagePack (понимаю, что последний — бинарный формат, но AXON тоже так умеет, так что было бы интересно посмотреть) + вы так и не ответили на вопрос про потоковую сериализацию/десериализацию.
Я к тому, что для конфигов есть yaml и HOCON (и насколько я вижу axon — heavily inspired by HOCON), а если для трансфера объектов, то читаемость отходит на второй план и на первое место выходит объём данных и производительность парсеров + возможность потокового разбора, о чём в статье ни единого слова нет.
Ну смотрите: client <=> frontend (вкупе с сервером) <=> frontend-backend-а <=> backend (голая бизнес-логика)
Уж не знаю как корректней назвать "frontend backend-а", но в целом это некий прокси который и берёт на себя всю эту лабуду с авторизацией, кешированием, балансировкой и прочим не связанным с бизнесом
Да как бы нет никаких проблем. Динамическая типизация же. Да и дело не стоит на месте.
Да как бы есть, и как раз те RFC их решают. И да динамическая типизация — зло (в отличие от выведения типов).
Про первый RFC: будет круто когда запилят, но просто то, о чём я говорю получится — не будет разницы между груви (например, или котлином) и пыхой, помимо наличия/отсутствия мультитрединга и охапки апачнутых библиотек.
Про второй: а вот это может и яву уделать с её ублюдским type-erasure, если конечно почеловечески сделают.
Про третий: а это типичный пример решения проблем, которые сами и создали — "у нас есть трейты, но трейты != интерфейсы, мы сами слабо представляем что мы сотворили и какую проблему этим решаем (читай нам было лень глянуть в сторону скалы), но надо что-то менять"
Я как раз наоборот говорил — надо заставлять пилить DTO и к состоянию сущностей напрямую мэпперы доступа не должны иметь.
Да, совпадает, но я не вижу большой проблемы запилить и просто в POJO (я лучше напишу POJO, для русского языка это более политкорретно нежели аналог для PHP) в простых случаях.
Но вот JSON скорее всего будет линейный.
Вот ну хоть убейте не могу представить как такое можно провернуть...
Не поверю, у меня есть опыт работы с Java и есть опыт работы с PHP...
У меня был опыт где флоу состовлялся из неких методов принимающих Map<String, Object> и возвращающих ровно тоже самое, в итоге всё сводилось к бесконечным проверкам на null и тайпкастам, не самое приятное занятие на свете. В PHP конечно проблем с тайпкастами не будет, но от null не убежишь. Нынче кстати в этом проекте перешли на специализированные RequestContext и мир стал чуточку прекрасней.
Не вышло десериализовать потому что какой-то проперти не хватает — вот тебе и валидация.
Ну почти, не считая длин строк, определённых форматов (например, поиск по номеру телефона: разрешены числа, "_" и "%", если присутствует "%", то длина не больше 11 символов, иначе ровно 11 символов), и прочие подобные бизнес-правила.
Это preflight запрос от CORS?
У нас есть If-Modified-Since и надо отдать 304
пользователь авторизован? Нет? 401
Эти вещи решаются написанием отдельно backend, отдельно frontend backend-a и отдельно морда. И тогда ваша бизнесс логика не будет страдать такой ерундой, делите обязанности.
Да пожалуйста: google://apache+camel+tutorial, google://spring-rest+tutorial, google://apache+camel+validation, google://scala+spray-routing+example (для тех, кто любит минималистичный DSL для объявления роутинга), ну и остальные технологии, которые я перечислял. Могу собственно ещё сразу приписать сюда примеры кода, но для всего этого многовато будет + для спринга это достачно некомфортно вспоминать из головы и писать прям тут.
Я категорически против того, что бы что-то мэпило данные на сущности. И Еще более против того, что бы у меня бизнес объекты были анемичны.
Вас никто не заставляет пилить DTO, это вполне могут быть нормальные такие сущности, с логикой. (Хоть я и не одобряю такой подход, но это уже вопрос вкуса)
А если так — я могу просто его десериализовать в динамическую структурку
Поверьте это ОЧЕНЬ замедляет разработку в итоге.
Можете поподробнее? Причем тут сферический в вакууме CRM, автомэпперы и композиция? Может я вас не понимаю.
Представьте себе некоторого сферического клиента, с адресом (да ещё и с регионом), с паспортными данными (да ещё и если только это ФЛ, а есть ещё ЮЛ, т.е. ИП, ЗАО, ООО,..), неким внутренним признаком, неким внутренним Л/Сч. Вот как это запихать в что-то плоское, не используя композицию объектов?
Вы точно знаете какой объем кода нужен?
Жутковатая, маловнятная охапка аннотаций, странного вида симфонические конфиги, мидлварь… FOSRest со всеми вытекающими странностями, магией с формами, если вдруг захотелось повалидировать и т.п.
Когда я вижу подобное первая мысль в моей голове: "Пытались сотворить EIP, но не осилили". А предыдущий подход больше всего похож на spray-routing и он был бы не плох, если бы его сделали полноценым DSL-м, но мне так и не удалось его застать.
Я это всё к тому, что PHP (в том числе к моему собственному удивлению) на сегодня эволюционировал в довольно пристойную экосистему
Я и не отрицаю, просто подмечаю, что есть инструменты получше, как и то, что "эволюционирует" PHP всё же слишком медленно.
см. анекдот про left-pad
С пакагистом будет ровно тоже самое, если ВДРУГ Фабиен выпилит свои компоненты. + я почти уверен, что помимо них есть что-то подобное на что тоже всё завязано.
я пожелаю удачи любителям Go, Erlang, F#
Вот кстати с эрлангом вы промахнулись: Р. Он стар и у него своя ниша, где его никто в ближайшем будущем не потеснит. Да и я ж не про "СУПЕРМОДНЫЕНОВЫЕТЕХНОЛОГИИ", а про вполне обкатанные (Java, Scala, Groovy) с тучей инструментов.
Да я про автомапперы (из ява мира это — JAXB, Jackson, Spray-JSON,… + аннотации для любимого фреймворка).
Для symfony/serializer нужно порядочно всего объяснять, в том числе опционально через JMS, хотя быть может всё изменилось с последнего момента как я с этим заморачивался.
Уж не знаю как вы засовываете в лиейную коллекцию объект какой-нибудь сферической в вакууме CRM, но как по мне значительно проще использовать композицию.
В случае любой ошибки?
Я про fail от findOrFail.
Валидация происходит на уровне пришедшей структуры (у меня вообще через json schema либо стандартным symfony/validation валидирую массивчики). Далее валидация идет на уровне бизнес логики.
Я больше про объём кода для этого необходимый, я прекрасно знаю как валидировать что-либо через symfony/validation и какой для этого нужен объём кода, особенно если хочется изменить формат выводимого сообщения. Это же всё просто призыв к сравнению и обмозгованию.
Как на счёт принять сложный json и мапнуть его на объект? (Кстати, что будет выведено в случае ошибки? [Правда интересно])
И после вышеописанного прикрутите сюда валидацию и каплю бизнес-логики.
P.S. Я ж не про крайности говорил, а про нормальный такой себе флоу.
P.P.S. Хотя надо признать этот пример впечатляет, особенно после продолжительного хватания за голову от документации Symfony + JMSSerializerBundle + PropertyЧЕГОТОТАМ (уже даже подзабыл)
Я про возвращаемые типы, которые не могут быть null и при этом напрочь отсутствуют дженерики, что убивает на корню возможность это хотя бы в монаду завернуть… Про массивы, итераторы и т.п. (вы думаю меня поняли)
Мы ж вроде про "со стороны разрабов" говорим… Или я просто что-то недопонял?
На самом деле наблюдается тенденция улучшения в этом плане последние пару лет.
Да, но для сравнения посмотрите как меняются js, python, java. Вот это тенденция к улучшению (особенно js), а у пыхи как-то с этим печально — да добавили нэймспэйсы с трейтами и тайпхинты, но при этом первым слабо пользуются, второе в принципе не понимают, а на третье частенько приходится забивать из-за отсутствия дженериков (про седьмую версию я просто молчу — это ж надо было додуматься ТАК сделать).
Да о чём вообще можно говорить если до сих пор живы kohana, codeigniter и т.п.?
По коммерческой стороне всё понятно. Я про сторону разрабов и про то, что мне не всегда понятен выбор неглупых разрабов в пользу пыхи.
У PHP и Java одна объектная модель.
Да, но у явы как ни странно сахара больше и кода для какого-нибудь реста писать надо порядочно меньше. Особенно ярко это на уровне сериализации/десериализации из json/xml и валидации всего этого чуда (посмотрите spring-rest (camel + camel-validation, для "небыдла") — поймёте о чём я).
По функционалу Doctrine не сильно уступает Hibernate
Ну не считая "магических интерфейсов" — да. А вот mybatis (запросы пишешь сам, маппятся автоматически) найти для пыхи несколько сложнее.
Вот честно, может быть вы просто видели плохие проекты на PHP?
Видел и плохие и хорошие, да и сам в общем-то писал. И как разработчик скажу — кода на пыхе нужно писать больше. А у ж хороший такой DSL в пыхе — очень большая редкость.
Если уж говорить про Kotlin, то тут про выразительность поверю.
Он кстати не плох, но если знаешь скалу, то не нужен совершенно (ИМХО). Груви с грельсами кстати пхпшнику будет ближе — очень похож на пыху, за счёт динамической типизации, а грельсы очень похожи на симфони.
Если огромное множество различных проектов, где я бы не стал брать PHP, с другой стороны, есть куда более огромное количество проектов, где PHP хорошо себе подходит.
Весь мой спич сводится к тому, что ниша пыха — динамические сайты, а мы живём в мире с одностраничными приложениями. А рест на пыхе — не самая приятная вещь. + в мире микросервисов пыха тоже достаточно ограничена (например хорошо спроектированные микросервисы на яве можно запустить как в одной jvm, так и на разных машинах)
И больше встает вопрос о культуре разработки.
Вот с этим-то в пыхе как раз всё и плохо. Большинство разрабов даже об ООП не слышало, какой там тех.долг, тесты и рефакторинг. Пару раз встречал кадров, которые смотрят на тебя круглыми глазами, когда ты им говоришь о тестах, кодстайле и CI.
Конечно в яве такое тоже встречается, но это в целом редкость. И да я видел говнокод на яве, но по "силе запаха" он не так плох как говнокод на пыхе.
Если разработчики на пыхе тесты пишут, знают что такое рефакторинг и технический долг — то я бы не особо парился.
А я бы сильно удивился, что они до сих пор остаются в гнилом напрочь сообществе. (Хотя быть может это только я Иуда свалил)
стериотип как «все php-ники быдло»
Проблема в том, что этот стереотип процентов на 80 верен, как бы это ни было печально.
Я конечно всё понимаю, но зачем писать о скале, будто это что-то сложное? Она же проще пыхи, лишь бы мозги были в правильную сторону развёрнуты (пяток акторов на акке, в слик и морду спрэя наружу = высокопроизводительное stateless [если конечно не совсем деревянный писал] приложение). Я конечно понимаю, что под скалу разрабов днём с огнём не сыщешь, да и тех, что найдёшь отправишь обратно (ЗП пхпшника * 3), но всё же.
Касательно большинства проектов: нынче в моде ресты, а как по мне значительно проще накидать элементарные контроллеры на спринге, сотворить POJO для hibernate и приправить аннотациями (для небыдла: роуты на кэмэле + сервисы в osgi для логики + mybstis с парой запросов + опционально конфиги в зукипере), чем громоздить неведомо что на пыхе (да симфони, да доктрина, да jmsserializer, но по объёму и выразительности кода — беда, это уже не говоря о производительности и масштабируемости).
Ээээ, где это Model 2 подразумевает, что модель живет отдельно от контроллера?
В диаграмме классов
Веб-формы здесь ни при чем, это в любом MVP так. Под «напрямую» я понимаю то, что не значение выставляется в модели, а потом представление интерпретирует это значение, а презентер напрямую говорит представлению «сделай поле красным».
В большинстве парсеров JSON-a используется потоковая обработка (по крайней мере в яве), так что этот выигрышь мимо кассы.
Раз для сериализации, то можно немного статистики по скорости сериализации/десериализации + средний объём данных в сравнении с JSON и MessagePack (понимаю, что последний — бинарный формат, но AXON тоже так умеет, так что было бы интересно посмотреть) + вы так и не ответили на вопрос про потоковую сериализацию/десериализацию.
А в чём конкретный профит?
Я к тому, что для конфигов есть yaml и HOCON (и насколько я вижу axon — heavily inspired by HOCON), а если для трансфера объектов, то читаемость отходит на второй план и на первое место выходит объём данных и производительность парсеров + возможность потокового разбора, о чём в статье ни единого слова нет.
Вот мы и получаем 3 логических сервера:
При этом, естественно, ничего не мешает держать их в пределах одного физического сервера.
А второй, как раз то, что я описал.
Уж не знаю как корректней назвать "frontend backend-а", но в целом это некий прокси который и берёт на себя всю эту лабуду с авторизацией, кешированием, балансировкой и прочим не связанным с бизнесом
Да как бы есть, и как раз те RFC их решают. И да динамическая типизация — зло (в отличие от выведения типов).
Про первый RFC: будет круто когда запилят, но просто то, о чём я говорю получится — не будет разницы между груви (например, или котлином) и пыхой, помимо наличия/отсутствия мультитрединга и охапки апачнутых библиотек.
Про второй: а вот это может и яву уделать с её ублюдским type-erasure, если конечно почеловечески сделают.
Про третий: а это типичный пример решения проблем, которые сами и создали — "у нас есть трейты, но трейты != интерфейсы, мы сами слабо представляем что мы сотворили и какую проблему этим решаем (читай нам было лень глянуть в сторону скалы), но надо что-то менять"
Да, совпадает, но я не вижу большой проблемы запилить и просто в POJO (я лучше напишу POJO, для русского языка это более политкорретно нежели аналог для PHP) в простых случаях.
Вот ну хоть убейте не могу представить как такое можно провернуть...
У меня был опыт где флоу состовлялся из неких методов принимающих Map<String, Object> и возвращающих ровно тоже самое, в итоге всё сводилось к бесконечным проверкам на null и тайпкастам, не самое приятное занятие на свете. В PHP конечно проблем с тайпкастами не будет, но от null не убежишь. Нынче кстати в этом проекте перешли на специализированные RequestContext и мир стал чуточку прекрасней.
Ну почти, не считая длин строк, определённых форматов (например, поиск по номеру телефона: разрешены числа, "_" и "%", если присутствует "%", то длина не больше 11 символов, иначе ровно 11 символов), и прочие подобные бизнес-правила.
Эти вещи решаются написанием отдельно backend, отдельно frontend backend-a и отдельно морда. И тогда ваша бизнесс логика не будет страдать такой ерундой, делите обязанности.
Увы да, в этом и проблема.
Вас никто не заставляет пилить DTO, это вполне могут быть нормальные такие сущности, с логикой. (Хоть я и не одобряю такой подход, но это уже вопрос вкуса)
Поверьте это ОЧЕНЬ замедляет разработку в итоге.
Представьте себе некоторого сферического клиента, с адресом (да ещё и с регионом), с паспортными данными (да ещё и если только это ФЛ, а есть ещё ЮЛ, т.е. ИП, ЗАО, ООО,..), неким внутренним признаком, неким внутренним Л/Сч. Вот как это запихать в что-то плоское, не используя композицию объектов?
Жутковатая, маловнятная охапка аннотаций, странного вида симфонические конфиги, мидлварь… FOSRest со всеми вытекающими странностями, магией с формами, если вдруг захотелось повалидировать и т.п.
Когда я вижу подобное первая мысль в моей голове: "Пытались сотворить EIP, но не осилили". А предыдущий подход больше всего похож на spray-routing и он был бы не плох, если бы его сделали полноценым DSL-м, но мне так и не удалось его застать.
Я и не отрицаю, просто подмечаю, что есть инструменты получше, как и то, что "эволюционирует" PHP всё же слишком медленно.
С пакагистом будет ровно тоже самое, если ВДРУГ Фабиен выпилит свои компоненты. + я почти уверен, что помимо них есть что-то подобное на что тоже всё завязано.
Вот кстати с эрлангом вы промахнулись: Р. Он стар и у него своя ниша, где его никто в ближайшем будущем не потеснит. Да и я ж не про "СУПЕРМОДНЫЕНОВЫЕТЕХНОЛОГИИ", а про вполне обкатанные (Java, Scala, Groovy) с тучей инструментов.
Для symfony/serializer нужно порядочно всего объяснять, в том числе опционально через JMS, хотя быть может всё изменилось с последнего момента как я с этим заморачивался.
Уж не знаю как вы засовываете в лиейную коллекцию объект какой-нибудь сферической в вакууме CRM, но как по мне значительно проще использовать композицию.
Я про fail от findOrFail.
Я больше про объём кода для этого необходимый, я прекрасно знаю как валидировать что-либо через symfony/validation и какой для этого нужен объём кода, особенно если хочется изменить формат выводимого сообщения. Это же всё просто призыв к сравнению и обмозгованию.
См. выше.
И после вышеописанного прикрутите сюда валидацию и каплю бизнес-логики.
P.S. Я ж не про крайности говорил, а про нормальный такой себе флоу.
P.P.S. Хотя надо признать этот пример впечатляет, особенно после продолжительного хватания за голову от документации Symfony + JMSSerializerBundle + PropertyЧЕГОТОТАМ (уже даже подзабыл)
Мы ж вроде про "со стороны разрабов" говорим… Или я просто что-то недопонял?
Да, но для сравнения посмотрите как меняются js, python, java. Вот это тенденция к улучшению (особенно js), а у пыхи как-то с этим печально — да добавили нэймспэйсы с трейтами и тайпхинты, но при этом первым слабо пользуются, второе в принципе не понимают, а на третье частенько приходится забивать из-за отсутствия дженериков (про седьмую версию я просто молчу — это ж надо было додуматься ТАК сделать).
Да о чём вообще можно говорить если до сих пор живы kohana, codeigniter и т.п.?
По коммерческой стороне всё понятно. Я про сторону разрабов и про то, что мне не всегда понятен выбор неглупых разрабов в пользу пыхи.
Да, но у явы как ни странно сахара больше и кода для какого-нибудь реста писать надо порядочно меньше. Особенно ярко это на уровне сериализации/десериализации из json/xml и валидации всего этого чуда (посмотрите spring-rest (camel + camel-validation, для "небыдла") — поймёте о чём я).
Ну не считая "магических интерфейсов" — да. А вот mybatis (запросы пишешь сам, маппятся автоматически) найти для пыхи несколько сложнее.
Видел и плохие и хорошие, да и сам в общем-то писал. И как разработчик скажу — кода на пыхе нужно писать больше. А у ж хороший такой DSL в пыхе — очень большая редкость.
Он кстати не плох, но если знаешь скалу, то не нужен совершенно (ИМХО). Груви с грельсами кстати пхпшнику будет ближе — очень похож на пыху, за счёт динамической типизации, а грельсы очень похожи на симфони.
Весь мой спич сводится к тому, что ниша пыха — динамические сайты, а мы живём в мире с одностраничными приложениями. А рест на пыхе — не самая приятная вещь. + в мире микросервисов пыха тоже достаточно ограничена (например хорошо спроектированные микросервисы на яве можно запустить как в одной jvm, так и на разных машинах)
Вот с этим-то в пыхе как раз всё и плохо. Большинство разрабов даже об ООП не слышало, какой там тех.долг, тесты и рефакторинг. Пару раз встречал кадров, которые смотрят на тебя круглыми глазами, когда ты им говоришь о тестах, кодстайле и CI.
Конечно в яве такое тоже встречается, но это в целом редкость. И да я видел говнокод на яве, но по "силе запаха" он не так плох как говнокод на пыхе.
А я бы сильно удивился, что они до сих пор остаются в гнилом напрочь сообществе. (Хотя быть может это только я Иуда свалил)
Проблема в том, что этот стереотип процентов на 80 верен, как бы это ни было печально.
Касательно большинства проектов: нынче в моде ресты, а как по мне значительно проще накидать элементарные контроллеры на спринге, сотворить POJO для hibernate и приправить аннотациями (для небыдла: роуты на кэмэле + сервисы в osgi для логики + mybstis с парой запросов + опционально конфиги в зукипере), чем громоздить неведомо что на пыхе (да симфони, да доктрина, да jmsserializer, но по объёму и выразительности кода — беда, это уже не говоря о производительности и масштабируемости).
В диаграмме классов
Спасибо, теперь я знаю чуточку больше :)