Делают я тут один проект.. и заодно решил для себя сделать небольшой движок, что бы использовать потом его в своих небольших проектах. И задумался насчет сессий, читал что современные фреймворки не используют нативные сессии, эмулируют их работу, хранят все данные в базе. Кстати не только фреймворки и не только современным) тот же SMF (движок форума) тоже насколько я помню хранит в базе все)) Насколько это оправдано и насколько это надо делать)) ??))
Нашел хороший пример, дырявый спамосборщик этот движок судя по проблемам здесь. Приведи аргументы чем пхп сессии плохи.
нормальный движок)) ни о каких проблемах не знаю)) а аргументов нет)) вижу просто что такая тенденция есть.
Ну с какой целью некоторые фреймворки (Laravel, к примеру) делают свои сессии на файлах - ХЗ. Но сессии на основе базы данных или к примеру Redis-а имеют важное преимущество - они могут быть не блокирующими. Иногда может быть полезно, чтоб фронт мог два параллельных запроса к бэку сделать.
Механизм сессий PHP тоже может быть неблокирующим. Сразу после открытия сессии файл можно отпустить. И синхронизировать его содержимое с массивом $_SESSION через хэндлер завершения приложения самому.
@Fell-x27, для этого надо телодвижения делать. Правда, если самостоятельно реализовывать сессии на redis-е, то тоже прилично телодвижений. Но готовые пакеты наверняка и фреймворконезависимые есть. Ну и Redis быстрее, в дополнение.
Продолжайте продолжайте Мне тоже интересно, почему ларавелька заюзала библию нежели использовать обычную сессию --- Добавлено --- Понятие авторов таковы - все интимные данные должны находится в базе данных
Потому что разработчики фреймворков часто видят в уже существующих инструментах один фатальный недостаток. Автор JQuery вот, настолько увлекся борьбой с фатальными недостатками JS, что написал свой собственный JS поверх существующего.
Я вот недавно заказчику накатал Код (Javascript): document.querySelector(".newYearHistory").forEach(/* ... */) А он мне: твой код не работает на некоторых андроидах и в IE 11. Оказывается, forEach не все браузеры поддерживают, из актуальных, надо полифилл делать. А если бы было $(".newYearHistory").each(/* */), то это были бы не мои проблемы.
Да люди не живут в рамках и создают успешные продукты, а фатальные недостатки в основном в коде а не в ЯП, поэтому и чистите тут спам
Надо бабель юзать. В нем все уже учтено. --- Добавлено --- Да, так на всякий, у нас тут не SMF, а Xenforo. И он хранит в базе даже CSS, прстгспди.
Да, так на всякий, Вероятность чего? Удачной синхронизации, потому как приложение может помереть мимо хендла в ряде случаев? Или ты про вероятность блокировки при параллельных запросах, попутно повышающую шанс на состояние гонки?
Нет, просто у тебя пока недостаточно знаний/квалификации, чтобы понять его. Это норм. Со временем нагонишь. --- Добавлено --- Ну, по дефолту, пыха ждет снятие блокировки сессии при обработке запроса. В данном случае, грубо, вместо блокировки на 0.01 секунду получаем блокировку на 0.00001 секунду. Это даже не окно, это игольное ушко. Ну а гонка...это уже зависит от того, что храним в сессии. В 95% это некие фундаментальные данные. Права доступа, логин там.. Они пишутся при инициализации единожды. Им гонка не страшна. А даже если бы страшна была, это какая плотность запросов нужна от живого человека, чтобы пробить вышеописанное окошко? Крч, мб на уровне сферического коня в вакууме проблема и не решена, но в реальности она не будет иметь место. Я вот для себя вижу такие плюсы в работе сессий на БД\мемкеше: 1) Отсутствие фрагментации ФС и задрачивания носителя. 2) Отсутствие геморроя при горизонтальном масштабировании. --- Добавлено --- Но оба пункта актуальны, только когда у тебя многие тысячи хитов в день. А до этого дожить надо.
А для этого есть облачные бак энд сервисы, а все эти фрагментации и дребезжание контактов это прошлый век
заложил возможность смены типа сессий)) что бы если что всегда можно было с нативных переключить на БД)
Сессии совсем не обязательно "имитировать" https://php.ru/manual/class.sessionhandlerinterface.html --- Добавлено --- На php.net есть на русском