мускуль или постгря умеют в jsonb

С этого момента подробнее можно

монгу можно выкинуть имхо. фалкон тоже, тут уже обсуждали, вкратце, все преимущества фалкона с выходом пхп7 сошли на нет, остался только головняк

От phalcon мне в основном нужны валидаторы, маршрутизаторы и прочее навесное

С этого момента подробнее можно

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

От phalcon мне в основном нужны валидаторы, маршрутизаторы и прочее навесное

почему именно фалькон? Если у тебя с ним опыт просто есть то тогда здраво

просто монга в этом трио точно лишняя

могу посоветовать добавить redis, незнаю ачем, прост я его очень люблю :-)

могу посоветовать добавить redis, незнаю ачем, прост я его очень люблю :-)

ну он пригодится как минимум)

и вшить симфони и ларавель, я их люблю

хотя конечно лучше по требованию такие штуки добавлять а не просто так

Господа, есть задача сделать большой расширяемый веб-сервис, в качестве фреймворка будет выступать phalcon. Не будет ли избыточным подход с тремя хранилищами данных MySQL - для контрольной информации (id, timestamp, и др) и связывания моделей ORM, MongoDB для хранения свойств сущностей (не строгая структура, CRUD выборки) и обособленный Elasticsearch для поддержания поискового индекса.

Зависит от решаемых задач. Такая связка вполне имеет место быть.

и вшить симфони и ларавель, я их люблю

ну вот я потому про фалькон и намекал - не люблю его

зачем редис? ради любви?

задачи то не было про редис

зачем редис? ради любви?

все ради кэша $$$

all you need is love <3

а монга зачем?

почему именно фалькон? Если у тебя с ним опыт просто есть то тогда здраво

Опыт небольшой, в основном я на laravel делал. Меня прельщает то что на загрузку самого Laravel уходит время, а phalcon уже в оперативе

Опыт небольшой, в основном я на laravel делал. Меня прельщает то что на загрузку самого Laravel уходит время, а phalcon уже в оперативе

пых то всеравно умирает

так какая разница

а монга зачем?

Монга только из-за crud выборок из коробки

Монга только из-за crud выборок из коробки

что значит "круд выборки из коробки"?

ну то есть ты можешь сгенерить CRUD для табличек в мускуле

давно чота пых умирает

все не умрет

https://docs.mongodb.com/manual/_images/crud-annotated-mongodb-find.bakedsvg.svg

давно чота пых умирает

он про модель работы

давно чота пых умирает

А из-за чего умирает то?

а не хоронит пхп

госпади

аа

ну то есть ты можешь сгенерить CRUD для табличек в мускуле

Я не хочу писать обертки

На фронте генерим json, проверяем через ACL доступность к полям выборки и если всё ок, скармливаем mongo

@fes0r пыха умирает и именно по этому у тебя канал по пыхе

Умирает = освобождает память он имел ввиду

это пиздец

пацаны пишут про пхп и не знаю что значит "умирающая модель"

чот у меня подгорело

Зависит от решаемых задач. Такая связка вполне имеет место быть.

Спасибо, основная задача состоит в описании бизнес логики в декларативном стиле, в такой архитектуре как я описал коллекции и политики можно задавать через JSON массив-выборку и хранить в MYSQL, а всю работу с данными вести в Mongo и при всём при этом не заботиться о поисковой оптимизации, кроме как на события изменения повесить обработчики, обновляющие индекс ElasticSearch. И прикрутить GUI для создания этих самых политик и коллекций.

Не углубляйтесь в обобщение

Обычно это усложняет код.

Вы это делаете скорее всего с мыслями о том, что он будет жить десятки лет.

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

Но потом вам подумается «А почему все так сложно? Мне нужно поддерживать какие-то безумные юзкейсы, а у меня тут нужно просто сделать то-то и то-то».

это пиздец

да расслабься, теперь знаем

Я согласен с вами, коллеги, что возможны плохие исходы такой реализации

Хотя, конечно, проекты бывают разные.

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

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

Ранил, убил. Именно по этим причинам

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

Смотря какой гуи

Если гуи будет подсказывать параметры и объяснять все, то не будут.

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

Согласен, но это вопрос UI\UX мы собираемся эти механизмы спустить до рядового пользователя. Drag'n'Drop, анимации и прочие ноухау интерфейсостроения.

или же окажется, что им отвертка нужна была, а вы им робота по серийной сборке... и 99% окажется, что 95% функций этого декларативного языка избыточна, но при этом нужно еще 100500 новых действий... в общем без группы въедливых выносящих мозг всем сис аналитиков я бы не стал в это ввязываться

ну удобная админка - это не декларативный язык... по сути последний как раз и нужен когда в ГУИ сложно заложить все функции

иначе получится не админка, а IDE ;)

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

Но если все же будете делать «настраиваемый через гуи» вариант не забудьте продумать логирование изменений, как будет осуществляться перенос настроек со стэйджинга (скорее всего нужна будет версионность для этих конфигов) и откат.

Потому что рано или поздно появятся вопросы. 1. Мы все настроили на тесте, потратили неделю, перенесите на прод. 2. Какой-то *** на проде изменил что-то и все сломалось 3. Мы перенесли новый код на прод но забыли перенести конфиги из гуи под новую фичу.

или же окажется, что им отвертка нужна была, а вы им робота по серийной сборке... и 99% окажется, что 95% функций этого декларативного языка избыточна, но при этом нужно еще 100500 новых действий... в общем без группы въедливых выносящих мозг всем сис аналитиков я бы не стал в это ввязываться

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

Имеется прототип в котором работают люди, полёт нормальный, там эта логика реализована через прослойку которая php массивы превращает в запросы к БД, и наоборот по этому же массиву объект из бд проверяется на принадлежность к выборке. Прототип на Laravel, массивы захардкожены а не хранятся в БД. Сейчас тот самый этап когда из концепции это должно быть переделано в полнофункциональный, масштабируемый сервис

ну без погружения в проект я бы не рискнул какие-то конкретные советы давать... а абстрактные никому не нужны ;)

И да, с фальконом я бы не связывался

Ну когда варишь это в голове, начинаешь думать - а не нахеровертил ли я очередной велик? Есть ли способ сделать проще? И подобное, а так как прототип я запилил один и ядро делаю один, мне поговорить особо не с кем, так как окружающие просто не понимают о чем я говорю.

И да, с фальконом я бы не связывался

Принял

И да, с фальконом я бы не связывался

Вполне нормальный фреймворк, звезд с неба не хватает, но вполне на нем написать пару проектов можно

Если ты один, ну лучше, конечно, идти по простому пути... не очень полезно для самосовершенствования, но потокми спасибо скажут ;) А что бы понять, что нужно на стороге ГУИ - нужно садиться с клиентами и как миниум несколько дней просто смотреть как они работают...

Вполне нормальный фреймворк, звезд с неба не хватает, но вполне на нем написать пару проектов можно

На C++ тоже пару проектов написать можно

А при чем здесь C++?

такое же специфическое решение получится

Если ты один, ну лучше, конечно, идти по простому пути... не очень полезно для самосовершенствования, но потокми спасибо скажут ;) А что бы понять, что нужно на стороге ГУИ - нужно садиться с клиентами и как миниум несколько дней просто смотреть как они работают...

я бы сделал апи и crud gui посадил пилить джс макаку, на какомнибудь реакте

Если ты один, ну лучше, конечно, идти по простому пути... не очень полезно для самосовершенствования, но потокми спасибо скажут ;) А что бы понять, что нужно на стороге ГУИ - нужно садиться с клиентами и как миниум несколько дней просто смотреть как они работают...

Именно так я и делаю, у нас тестовая среда 20 клиентов 6 сотрудников, тестируем концепцию работы и концепцию ПО. ГУИ собираю на этом https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S, много чего сделано, только скомбинировать. Приложение B2B, интерфейсы - формы\таблицы

платный AdminLTE?

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

платный AdminLTE?

ага

есть сборка под реакт

А если уж скорость бутстрап операций критична, то стоит смотреть в сторону микрофреймворков или чистого пхп - оно побыстрее чем фалкон будет, а то и просто на го написать ;)

вот го очень интересно

Но что то не решаюсь на нем писать без особого опыта

А если уж скорость бутстрап операций критична, то стоит смотреть в сторону микрофреймворков или чистого пхп - оно побыстрее чем фалкон будет, а то и просто на го написать ;)

У Phalcon есть режим микрофреймворка, его то я и хотел использовать

А если уж скорость бутстрап операций критична, то стоит смотреть в сторону микрофреймворков или чистого пхп - оно побыстрее чем фалкон будет, а то и просто на го написать ;)

Ну ну. И на чистом PHP со временем напишем все тот же фреймворк, только СВОЙ..

Это страшилка для начинающих ;) Ну, даже не совсем страшилка, у них так и получится, скорее всего.

От фреймворка мне нужны базовые вещи, я не хочу писать роутер, не хочу писать систему событий, не хочу писать валидаторы, я просто хочу получить это всё из коробки. А уже разводя на нужные методы, подписываясь на события и валидируя данные писать саму суть.

У Phalcon есть режим микрофреймворка, его то я и хотел использовать

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

чем фалкон для него лучше, чем... ну.. ларавель?

с учетом "медленно развивается", "и вам не сюда" ;)

У Phalcon есть режим микрофреймворка, его то я и хотел использовать

у симфони тоже)

микрокернел

Используйте Siler :)

Я всё таки думаю что будущее за golang, к тому же NGINX Unit размывает границы использования различных языков в одном проекте, но пока с golang нет практики, а работа не ждёт, писать буду на пыхе.

Используйте Siler :)

silex?

golang ))))))

по сути разница только в вещах которые по дефолту включены. Если проект большой по итогу выйдет тоже самое. Вместо того что бы пытаться на начальнм этапе сэкономить 10 милисекунд может быть стоит продукт запилить для начала?

nginx unit не делает ничего ;) что уже не было сделано ;)

silex?

siler :) https://github.com/leocavalcante/siler

siler :) https://github.com/leocavalcante/siler

ну да, и упереться потом в чтение с диска)

Я всё таки думаю что будущее за golang, к тому же NGINX Unit размывает границы использования различных языков в одном проекте, но пока с golang нет практики, а работа не ждёт, писать буду на пыхе.

можешь еще глянуть в сторону php-pm

и похожих солюшенов

для read-only запросов например - уменьшить лэтенси