[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: ⚙️ Laravel Settings (настройки в БД)
Rand
Всем привет!

Написал свой пакет для Laravel, служащий для сохранения настроек в БД, необходимость такая возникает довольно часто, но не все существующие решения на GitHub меня устраивают, где-то не хватает функциональности, где-то не очень удобное API, поэтому взялся за реализацию наиболее полного решения сам. В общем, проблема такая, что нужны пользователи стимулирующие прогресс. Документация на англ. сейчас, думаю в целях набора аудитории сделать пост на reddit или подать клич в slack, но ещё рано, хотелось бы протестировать малыми силами и улучшить. Поэтому, если есть разработчики работающие с Laravel прошу посмотреть, протестировать и высказать своё мнение, что следует сделать.
Заранее благодарен.

GitHub:
https://github.com/Rudnev/laravel-settings
twin
Прикольно получилось. Было бы круто, если бы под лару не заточено. Я бы попробовал.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Michael
Что бросилось в глаза:
1) Remove the value : Settings::forget
Почему бы не назвать remove?
2) Из документации не видно какие типы можно сохранять.
Если глянуть внутри то ты используешь json_encode которая не восстановит тип объекта, плюс там ньюансы с приватными полями.
3) Хорошая идея со scopes() , но тут следующее:
- кидать этот функционал в AR модели с советом "it's better" не выглядит хорошей идеей с точки зрения ООП (SRP).
- первое что подумалось, что неплохо было бы использовать эти scopes для сохранения настроек в разрезе мультиязычности, но там сразу предостережение что такое не кешируется
4) Независимость от хранилища - большой и жирный плюс. А если возвести хотелки в абсолют то можно было бы в set/get указывать конкретное хранилище, чтобы одновременно можно было хранить в разных.
5) К такому расширению неплохо было бы создать второе, более высокоуровневое, которое из коробки даст пользователю админку по управлению настройками. Делал как то такое для мультиязычного сайта, там тоже работы немало оказалось чтобы все это сделать юзабельным.

_____________
There never was a struggle in the soul of a good man that was not hard
Rand
twin
Спасибо. Присутствуют зависимости от фреймворковского кэша, диспетчера событий, утилит для работы с массивом и работы с базой. Был бы пакет более низкоуровневый конечно сделал бы его отдельным, а так Laravel - сижу на нём плотно :)

Michael
Спасибо за потраченное время и советы.

Цитата (Michael @ 18.09.2018 - 12:04)
1) Remove the value : Settings::forget
Почему бы не назвать remove?

Компромисс с пользовательским опытом. Разработчики Laravel всюду используют put вместо set и forget вместо remove/delete. И если с put я не хотел мириться, то на forget всё-таки согласился. Вообще это одна из проблем дизайна фреймворка на мой взгляд, например для совместимости с PSR-6 им пришлось добавлять псевдонимы методов в экземпляр кэша, что в конечном итоге может привести к путанице и отсутствию единого стиля у конечных пользователей.

Цитата (Michael @ 18.09.2018 - 12:04)
2) Из документации не видно какие типы можно сохранять.

Над этим я обязательно ещё подумаю, но пока что не уверен, что в БД хорошо хранить сериализованные объекты, т.к. среда которая работает с базой может быть гетерогенной, записали данные на PHP, а читаем с микросервиса на Go, лично я бы логикой восстановления объекта занимался сам. Но вообще, можно подумать над внедрением расширяемых классов-сериализаторов.

Цитата (Michael @ 18.09.2018 - 12:04)
3) Хорошая идея со scopes() , но тут следующее:
- кидать этот функционал в AR модели с советом "it's better" не выглядит хорошей идеей с точки зрения ООП (SRP).
- первое что подумалось, что неплохо было бы использовать эти scopes для сохранения настроек в разрезе мультиязычности, но там сразу предостережение что такое не кешируется

Кэширование - на данный момент это то, что мне не нравится в этом пакете больше всего, во многом это связано с реализацией файлового кеширования в самом Laravel: один ключ - это один файл, при этом нет возможности делать тэг на группу объектов кэша (например, по имени вендора пакета), т.е. либо каждый запрос читай потенциально огромный файл кэша с абсолютно всеми настройками для всех пользователей, либо разбивай на отдельные файлы, но с невозможностью централизованного удаления всех данных, которые пакет закэшировал (т.к. пользовательские ключи заранее неизвестны), пробовал решать отдельным файлом-индексом, но пока как-то не очень, появляется проблема с race condition. Трейт модели чем хорош, что он загружает все настройки из базы относящиеся к модели один раз, а если делать через обычный scope-метод, там каждый вызов метода get это обращение к хранилищу. Тут таже проблема с кэшем, заранее название скоупов неизвестно, соответственно, кэшировать конечно можно, но централизованно удалить потом проблематично. А удалять важно, особенно во время разработки, когда база перенакатывается 10 раз на день и данные генерируются через Faker.

Цитата (Michael @ 18.09.2018 - 12:04)
4) Независимость от хранилища - большой и жирный плюс. А если возвести хотелки в абсолют то можно было бы в set/get указывать конкретное хранилище, чтобы одновременно можно было хранить в разных.

Так можно же:
Settings::store('database')->get('foo');
Settings::store('mongo')->get('foo');

Цитата (Michael @ 18.09.2018 - 12:04)
5) К такому расширению неплохо было бы создать второе, более высокоуровневое, которое из коробки даст пользователю админку по управлению настройками. Делал как то такое для мультиязычного сайта, там тоже работы немало оказалось чтобы все это сделать юзабельным.

Да, есть в планах.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.