но хайлод на люмене/лара - смешно

дада, смешно, плозому танцору всегда что то помешает монолитом может и не вывезет, хотя думаю побыстрее самописного говна. тут же msoa

не знаю

дада, смешно, плозому танцору всегда что то помешает монолитом может и не вывезет, хотя думаю побыстрее самописного говна. тут же msoa

в чем проблема монолита

лол

а в чем проблема laravel и хайлод? оверхеды минимальные

Из фреймворков тормознее ларвела только symfony, даже тесты были

да все эти бенчмарки - взяты вообще с левых задач и примеров

несколько rest\protobuf api нод и там уже не столь важно ларавел там или что иное

на практике все работает совершенно иначе

в хайлоаде решает не скорость выполнение скриптов

в хайлоаде решает скорость выполнения скриптов

лол)

именно что скорость работы логики приложения и решает

в хайлоаде решает с каким количеством подключений справиться приложение

можно писать хоть на ассемблере, только дольше и сложнее. не одними только бенчами стек технологий определяется

в хайлоаде решает с каким количеством подключений справиться приложение

лооол

при чем тут хайлоад

да все эти бенчмарки - взяты вообще с левых задач и примеров

Чем больше абстракций, интерфейсов и наследований тем тормознее всё работает

лучше 100к подключений со скоростью выполнения 2 секунды, чем 1к со скоростью выполнения 0.05

удобство и простота реализации кода, не менее важный пункт. особенно когда в команде работаешь. имхо, конечно

Чем больше абстракций, интерфейсов и наследований тем тормознее всё работает

Кто тебе такое сказал

абстракции, интерфейсы и наследования - это все для исключения дублирования кода

Чем больше абстракций, интерфейсов и наследований тем тормознее всё работает

Мерил лично поди небось))

лучше 100к подключений со скоростью выполнения 2 секунды, чем 1к со скоростью выполнения 0.05

что за цифры с неба вообще

все зависит от приложения

может мне нужно менее чем за секунду запрос обрабатывать

ничто не мешает хайлоад масштабировать и добавлять ресурсы

ничто не мешает хайлоад масштабировать и добавлять ресурсы

горизонтально

да

вопрос лишь в том, насколько быстро отработает логика

а количество обрабатываемых запросов - это уже масштабирование

Давайте, не будем холиварит на эту тему, это бесполезно. У каждого своя кухня. На моей кухне так выгоднее, от монолита php переходить на микросервисы на lumen. А уж потом по одному хоть на пйтон хоть на си переписывать.

какая разница где микросервисы

лол

это паттерн а не реализация

в таблице topics - topicable_id и topicable

Тут такой вариант тоже не подходит, думаю

и SOA и монолит может работать с одинаковой скоростью

вопрос лишь в проблема масштабирования такого приложения

и SOA и монолит может работать с одинаковой скоростью

Может, но его поддерживать сложнее

это зависит от приложения

даже в крупном приложении не всегда SOA уместен

это зависит от приложения

1,5 строк кода на php с 2000 года

даже в крупном приложении не всегда SOA уместен

Согласен

фолли ваще на Yii пишет, не слушайте изменника

я свой проект на ларке буду писать

хайлоад кстати

ну, в перспективе

обработка кучи уведомлений

кучи - это миллионы в минуту?

ну

десятки тысяч в секунду возможно

Так что с вопросом, в ларавеле для партиционирования ничего такого нету ?

не позскажу по твоему вопросу

И никто из здешних я так понимаю с этим в ларе не сталкивался?

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

надо на ларавел, делай как там принято

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

Так что с вопросом, в ларавеле для партиционирования ничего такого нету ?

это же фишка у бд

а не у фреймворка на пыхе)

Ну "псевдо"-партиционирование

На стороне mysql не никакого партиционирования, к сожалению. Тогда бы и вопрос отпал

legacy код решал это описанием все таблиц во FROM

лучше "псевдо" не городить)

тобишь join'ами

лучше "псевдо" не городить)

Это понятно. Но не у всех как у вас все так просто, алтер тейбл сделал и пили дальше.

Тут альтер запросы, равноценны выстрелу себе в ногу

я вот думаю, как мне делать гейтвей для апи

нужна быстрая софтина обрабатывающая апи токен

Был докладик на эту тему в том году, на Highload'e

JWT

думаю для этого что то кроме пыха взять

наверное это будет голанг

Там воможно и не пыха была, я не помню

либо lua, т.к. на нем дофига гейтвеев готовых

либо lua, т.к. на нем дофига гейтвеев готовых

в nginx нынче js есть, можно и на нем попробывать)

я вот думаю, а если к токену пользователя добавлять какую-то доп информацию, это ничего?

например тип пользователя. например в 3 первых символа токена

что бы не сверять тип в бд дополнительной логикой

Например есть юзер. Всего есть 10 типов пользователя. Для одного юзера для РАЗНЫХ типов генерируется разный токен. И в чем суть - вместо этого делать юзеру один токен, но при этом добавлять впереди тип

типо

абстракции, интерфейсы и наследования - это все для исключения дублирования кода

Шо ? Кони, люди, все смешалось. Интерфейсы никак не помогают исключать дублирование кода. Интерфейсы нужны для реализации модульности и слабой связанности.