TS
Ни одному здравомыслящему человеку не придет в голову идея строить цепочки из функций которые выполняются последовательно и пихать это в самое высоконагруженное место.
а якщо всьо шо робить мідлвар — перевіряє чи кука на місці?
Size: a a a
2019 October 28
A
а якщо всьо шо робить мідлвар — перевіряє чи кука на місці?
Проблема в их наличии и количестве.
TS
а якщо в мене мідлвар, який просто перевіряє чи роль юзера дозволяє зробити якусь фігню (повішав його на неймспейс в адмінці, яка ніколи в житті не буде мати більше 2-3 запитів в секунду)?))
TS
от що і я хочу сказати
це хороший інструмент, який дозволяє реалізувати отаку логіку, звісно ж не треба на будь яку херню створювати ше один, тіпа чисто шоб був, бо хочеться “перевикористати” його
це хороший інструмент, який дозволяє реалізувати отаку логіку, звісно ж не треба на будь яку херню створювати ше один, тіпа чисто шоб був, бо хочеться “перевикористати” його
TS
от що і я хочу сказати
це хороший інструмент, який дозволяє реалізувати отаку логіку, звісно ж не треба на будь яку херню створювати ше один, тіпа чисто шоб був, бо хочеться “перевикористати” його
це хороший інструмент, який дозволяє реалізувати отаку логіку, звісно ж не треба на будь яку херню створювати ше один, тіпа чисто шоб був, бо хочеться “перевикористати” його
Мидлвары часто конфликтуют из-за зацепления через контексты. Это вы 1-2 навесили, а сколько их из коробки идет + навешиваются зависимостями...
V
в несте вроде мидлвары не юзаются для всего как в экспрессе, а для редких случаев, но я сам его не тестил тоже
TS
в мене фастіфай, хз скільки там їх, але вроді кажуть шо то “самий швидкий”, я ж обрав його через те, шо він змушує розробників писати json-схеми, які описують вхідні/вихідні дані, що дозволяє генерувати свагер-доку) можливо не самий швидший, проте DX і можливість підтримки тут куди важливіше, вузькі штуки можна буде завжди переписати
A
В фастифае мидлвари существуют только для ленивых или мигрирующих с експреса. И в 3-й версии от них планируют отказаться или как минимум деприкейтнуть.
IS
А яка альтернатива мідлварям? Explicitly викликати в усіх хендлерах цю логіку?
TS
В фастифае мидлвари существуют только для ленивых или мигрирующих с експреса. И в 3-й версии от них планируют отказаться или как минимум деприкейтнуть.
Ну там є всякі хуки типу onRequest
A
Ну там є всякі хуки типу onRequest
Да. Хуки и мидлвари - то чуть разные вещи, хоть и внешне похожие
TS
Ти в фастіфаї тоже схеми пишеш?
A
Ти в фастіфаї тоже схеми пишеш?
Ну не даром же я модуль для генерации свагрера по схемам писал :)
TS
А, то твій?))
Лол, дякую, топова хрінь)
Лол, дякую, топова хрінь)
TS
А яка альтернатива мідлварям? Explicitly викликати в усіх хендлерах цю логіку?
1. Вариант с монолитным ядром фреймворка, которое делает все и парсит протокол и пишет в логи и сессии держит и буферизация и таймауты и парсинг json и маршрутизация запросов и обработка ошибок и т.д. в общем все. А оно вообще все всегда и нужно, а цельное ядро это всегда сделает быстрее и лучше.
2. Все на событиях, когда можно на все перечисленные функции навешивать события. А уже фреймворк события в нужном порядке вызывает, чтобы не было конфликтов и не было сильного сцепления между обработчиками.
2. Все на событиях, когда можно на все перечисленные функции навешивать события. А уже фреймворк события в нужном порядке вызывает, чтобы не было конфликтов и не было сильного сцепления между обработчиками.
2019 October 29
IS
1. Вариант с монолитным ядром фреймворка, которое делает все и парсит протокол и пишет в логи и сессии держит и буферизация и таймауты и парсинг json и маршрутизация запросов и обработка ошибок и т.д. в общем все. А оно вообще все всегда и нужно, а цельное ядро это всегда сделает быстрее и лучше.
2. Все на событиях, когда можно на все перечисленные функции навешивать события. А уже фреймворк события в нужном порядке вызывает, чтобы не было конфликтов и не было сильного сцепления между обработчиками.
2. Все на событиях, когда можно на все перечисленные функции навешивать события. А уже фреймворк события в нужном порядке вызывает, чтобы не было конфликтов и не было сильного сцепления между обработчиками.
Логічно, дякую 👍
Б
1. Вариант с монолитным ядром фреймворка, которое делает все и парсит протокол и пишет в логи и сессии держит и буферизация и таймауты и парсинг json и маршрутизация запросов и обработка ошибок и т.д. в общем все. А оно вообще все всегда и нужно, а цельное ядро это всегда сделает быстрее и лучше.
2. Все на событиях, когда можно на все перечисленные функции навешивать события. А уже фреймворк события в нужном порядке вызывает, чтобы не было конфликтов и не было сильного сцепления между обработчиками.
2. Все на событиях, когда можно на все перечисленные функции навешивать события. А уже фреймворк события в нужном порядке вызывает, чтобы не было конфликтов и не было сильного сцепления между обработчиками.
Может тогда и база данных не нужна? Писать все изменения в аппенд-лог и парсить при старте в память. Заодно и орм будет не нужна так как в памяти можно сразу хранить граф объектов связанных ссылками и работа с ними будет удобнее любой орм
TS
Может тогда и база данных не нужна? Писать все изменения в аппенд-лог и парсить при старте в память. Заодно и орм будет не нужна так как в памяти можно сразу хранить граф объектов связанных ссылками и работа с ними будет удобнее любой орм
Думаешь в правильном направлении
VY
Может тогда и база данных не нужна? Писать все изменения в аппенд-лог и парсить при старте в память. Заодно и орм будет не нужна так как в памяти можно сразу хранить граф объектов связанных ссылками и работа с ними будет удобнее любой орм
Это же не о всей базе идет речь? А только настройках/конфигах....?
AS
Это же не о всей базе идет речь? А только настройках/конфигах....?
О всей. Посмотрите уроки по Event Sourcing.