У меня просто сервис, который создаёт энтити, хочется чтобы был независимый, т.е. По сути надо и там ещё валидацию

А так, данные там есть, конвертер пихает :)

У меня просто сервис, который создаёт энтити, хочется чтобы был независимый, т.е. По сути надо и там ещё валидацию

нормально ли делать две валидации?

У меня просто сервис, который создаёт энтити, хочется чтобы был независимый, т.е. По сути надо и там ещё валидацию

Это все тот разговор, где мы говорили про валидацию?))

Я думал, разобрали тогда ?

Сервис этот - это API или просто сервисный класс, который можно переиспользовать?

Если второе, то решение очевидно, нужно делать внутри него валидацию - т.к. задача стоит его сделать максимально независимым

Да вот вроде разобрали, но сейчас какая-то каша получается

давай еще раз, какой ход запроса к данному сервису и какие планы по его использованию

Это сервисный класс, который использует апи для создания энтити, нужны определенные роля

Поля

Он просто создаёт энтити с определенными полями.

Сетит поля значениями, чтобы не делать этого в контроллере

И данные для этого берутся из метода этого сервица, который был дернут из-вне

Часть из реквеста передаётся, часть из стороннего сервиса

http://verraes.net/2015/02/form-command-model-validation/

http://verraes.net/2015/02/form-command-model-validation/

это понятно. проблема в другом же. Т.к. у меня ентити создается в сервисе, делать валидацию в контроллере и в сервисе этом норм? Валидация формы имеется ввиду

Валидацию формы в форме, но на уровне контроллера вызывается. А на уровне сервиса - валидация аналогичная валидации в команде, если уж команды не используются.

Ребят, как сделать дамп не на всю ширину экрана? У меня dump с отладчика при наводке, ростягивается на всю ширину.

exit(var_dump(....));

https://toster.ru/q/119319

Is Sylius suitable to migrate existing legacy application without classes to patterns/framework?

это понятно. проблема в другом же. Т.к. у меня ентити создается в сервисе, делать валидацию в контроллере и в сервисе этом норм? Валидация формы имеется ввиду

Я честно говоря не вижу смысла валидировать в 2-х местах. Если в контроллере валидируется, то фактически контроллер - это и есть твой сервис, который принимает входные данные, валидирует и возвращает результат. А если он прокидывает данные другому сервису, то он должен выступать как пайп, т. е. как канал связи, не более. Его цель не обработать данные, а передать. Только это нормально, если твой сервис возвращает ошибки в таком же формате что и контроллер. Имхо. P.s. Если ещё актуально.

Спасибо. Решил сделать сервис, который будет просто принимать входящие параметры. И делать всю работу (что-то сам, а что-то передавать другим сервисам)

Так и разделение ответственности получится и тонкий контроллер

всем утра !

сижу думаю, сф быстрее или рельсы

если приложение будет с БД общаться по средством АПИ, какое кол-во запросов посылать одновременно можно ?

если 500к запросов разом, тупить будет ?

если 500к запросов разом, тупить будет ?

тут наверное больше от сервера зависит, и оптимизации самих запросов

запросы, обычные гет, пут, дел

большая часть гет

запросы, обычные гет, пут, дел

оптимизации запросов к базе

и пут

+ кеш подрешает

и пут

да и вообще можно микрофреймфорк заюзать, если тебе фуллстек не надо

вообще мне нужно приложение иос свызать с mysql

кроме того, как написать апи, пока других вариков нет

кроме того, как написать апи, пока других вариков нет

На мой взгляд, только апи и вариант. + рядом еще поставить редиску, а у апи сделать, чтобы оно там все кэшировало

привет, тезка !

привет, тезка !

привет

так что, не городи огороды и делай АПИ. Статейку полистай, что я кидал, с хайлоада

я акцент делал на бд реалм, и синхронизацию. И понятно, что это херня все, и опять пришел к тому что нужно АПИ

нужно больше конкретики

разные ситуации по разному разгуливаются

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

в 90% случаях ты упрешься все равно в базу

если 500к запросов разом, тупить будет ?

Полмиллиона запросов к API в секунду – это приблизительный рейт Фейсбука нынешний

Полмиллиона запросов к API в секунду – это приблизительный рейт Фейсбука нынешний

а где почитать можно про это?

https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1 > Facebook handles about 175k requests per second (900k users on the site in any given minute, assume an action is taken every 5 seconds). And this probably doesn’t include API requests, which are a better analogue and probably 3–4x higher. Ну или вот такие люди тоже немаленькие: https://appsignal.com/30billion а рейт всего 12k/sec. У здоровенной платежной системы Stripe: https://twitter.com/patrickc/status/788752160284487680?lang=en 1200/sec

и все по АПИ?

А есть другие способы клиенту от сервера данные получать?

привет, Вить !

и тебе привет

что-то мне слабо в это вериться, что такой поток запросов, и бэку хоть бы хны

Так это ж горизонтально скейлящиеся системы

кеш, масштабирование. у них в общем-то не одна тачка в подсобке стоит.

Вот поточнее инфа за 2017 года подъехала про ФБ, кстати, если кому интересно: https://developers.facebook.com/blog/post/2017/04/18/graph-api-v2.9/ > The Graph API serves an average of 1.2 trillion API requests per day and powers some of Facebook's most popular products including Messenger and Instagram. FB + Messenger + Instagram = 14 млн/сек

Виктор, а вы FOSRestBundle+JMSSerializerBundle используете ? или свой велосипед ?

именно его

ну, в смысле первый вариант. ) странно отвечать "да" на вопрос с "или" )

)

на самом деле поглядываем на дефолтный симфоневский сериализатор, но мучают моменты. активно в JMS используем виртуальные свойства и пре\пост обработчики. в документации подходящей замены не увидел. вот вопрос, я слепой или не завезли?

откажитесь от jsm

лучше стандартный + кастомные нормалайзеры

у нас 90% проектов - мобильные прилаги и бек под них, jms- зло

Ребят, пожалуйста объясните мне, я из деревни))) какая разница каким сериалайзером пользоваться? Они же предназначены просто для того чтобы конвентировать один формат в другой) и должны по идее как одинаково работать...

Ну, как минимум функционал немного разный, что накладывает некий отпечаток на то, как организован итоговый код. Ну и реализованы они возможно по разному, следовательно чего могут отличаться по скорости, но это не точно. Хотя аргументы против JMS мне было бы интересно послушать.

мдээ

у кого какие мысли, почему ? может быть такое

у кого какие мысли, почему ? может быть такое

Кодировка нета?

у кого какие мысли, почему ? может быть такое

а что там не так?

дейсвительно, всё так !

ты считаешь, что он верно отдает ?

ну вообще это верно. если ты обратно сделаешь json_decode, получишь вполне вменяемый текст.

а вообще у json_encode есть флаг, UNESCAPE_UNICODE или как-то так. дока в помощь.

это если прям очень хочется человекочитаемый json, но непонятно зачем.

меня вообще больше SUCCESS капсом пугает. откуда этот вывод?

Json encode по умолчанию без флагов должен всё правильно выводить. Мб в базе кодировка не та?

в базе utf8 везде

не должен он так отдавать

он нормально, должен отдавать

А в базе нормальные значения хранятся?

да

и тут прописал, такая же херня

Там русские символы?

lf

да

да

это и есть utf

А делал var_dump die русского слова?

англ. он все ровно выводит