Комментарии 24
Чем ваше решение лучше бесплатных решений? Какое комьюнити вы собираетесь организовать вокруг решения? Если мне для разработки сайта с вашим готовым кодом все равно надо нанимать разработчика , то что же в этом готового? Как у вас с поддержкой? Исходники в открытый доступ для независимой оценки экспертами с хабра не желаете выложить?
P.s. предпочел бы symfony в место codeigniter
а можете объяснить, почему бы предпочли Symphony?
В сравнении с codeigniter, например можно было бы в терминале все Entity и crud для всех сущностей надиктовать включая связи, а формбилдер симфонишный ещё и времени сэкономит, не понимаю почему ещё против scss, когда он даже в bootatrap присутствует. В общем в сухом остатке я на симфони сделал бы такой объем работы тупо быстрее и качественнее, чем писать весь бойлерплейт на codeigniter
А вы уверены что человеку с простым сайтом нужны все эти ваши Entity и CRUD?
Не знаю как Simfony, возьмите Hello world на Laravel и CodeIgniter4, сделайте ошибку и посмотрите стэк трейс
У Laravel - около 40 вызовов функций (большая часть из них из библиотек Symfony)
У CodeIgniter - 5
Используется по сути один сервис фреймворка (роутинг), и 40!!! вызовов
Посмотрите бенчмарки по производительности по PHP фреймворкам. CodeIgniter4 в топе
Это прекрасный фреймворк, особенно для API
Всегда скептически отношусь к таким сравнениям. Очевидно же, что в песочнице код которого меньше, будет работать побыстрее. Но это на короткой дистанции. Нужны ли ентити? Ну в codeigniter есть cmodel ,что по сути тот же подход работы с моделью. Так где бд там и crud, странный вопрос. Далее орм над бд, вы или руками все прописываете и в пхпадмин сидите, или руками составляете миграции, что в 2023 году мне делать лень, да и орм делает это лучше меня. Ну и в конечном подходе можно сказать, что твиг тоже можно выкинуть и склеивать строчки самостоятельно, так быстрее же в коде будет. Я писал на codeigniter 6+ лет, мне надеоло писать бойлерплейт видя как другие программисты делают тоже самое за секунды из терминала
cmodel был в прошлой версии 5 лет назад
Да, в CI есть ActiveRecords, Entity, шаблонизатор, spark для команд и кодогенерации и другие основные сервисы современных бэкенд фреймворков. Но без монструозности "старших" братьев.
В ентерпрайзе где я работал так и не встретил его, по этому ушел на симфони раньше чем появились эти фичи. 10+ лет уже не доходят переписать проект с пхп 5.6 на 8 у одного из сайтов, все работает и так приемлемо)
З.ы я вообще фронтендер и симфони учил из-за того что на трёх работах подряд она на беке, да и порог входа у нее весьма демократичный
Странно, что не взяли в пример phalconphp, он же вообще модулем шел (или еще досихпор идет) и по многим тестам производительности быстрее даже чем CI.
Сейчас к сожалению диктует условия бизнес и бюджет. Было время когда я работал на phalconphp и некоторые из нас оглядывались на laravel, на то время еще его 5 версию... Проблема была в том, что мы делали многие вещи днями, которые на laravel можно было сделать за несколько часов, при этом сжигали бюджет... Но наш лид не хотел уходить с фалькона именно трактуя это скоростью работы фреимворка, которая по факту на начальных дистанциях в целом никому не нужна - важно выпустить жизнеспособный продукт, а дальше уже заниматься оптимизациями и прочим перфомансом и жонглированием.
Что в итоге мы имели ? На фальконе проект делался долго, тимлид успел уйти из компании, а новый пришедший тимлид сказал, что все хрень и php вообще не язык, а еще он очень медленный - пишем все на java (spring mvc).
В результате - всегда найдется "умник", который скажет, что все полная фигня и надо переделать на то-то...
Какие именно вещи делаются Ларавеле часы, а на Phalcon/CI - дни? (Разница в порядок)
Эх, писал длинный текст и редактор хабра решил, что много разглагольствую и очистил ввод :(.
Если короче, это было 7 лет назад может немного больше и я уже не очень хорошо помню все с чем сталкивались. Что помню, на тот момент у нас были проблемы в основном с рутиной. В фальконе не адекватно работал DI, потом у нас началась проблема со слоем ошибок. Учитывая, что писали API, у нас было очень много валидаций входящих параметров и описание валидаций, часто добивало, что нельзя было навесить глобальный trim, постоянные массивы строк с правилами валидации и самое печально, инкапсулировать в отдельный слой реквест запросы и инжектить их в контроллеры было просто не возможно, из-за чего шли по документации и писали валидацию прямо в методах контроллера, в последующем вынеся конечно в файлы обертки, но вся эта петрушка скорее сократила контроллеры, но не сократила рутину, только прибавила. В то время ручной работы на фальконе, было больше чем если пользоваться готовой абстракцией ларавеля, которая почти неосознанно постепенно появлялась в проекте но реализованная уже в ручную. Тот же ORM ларавеля, но наш лид почему-то очень любил phql (почему конечно стал понимать со временем, но снова таки многие вещи на raw можно было переводить постепенно и точечно, там где они серьезно нужны) и мы просто постоянно вынуждены были писать чистые запросы, даже если это обычный select для одной модели, кормить их modelManager'у и получать модель. Когда в laravel это уже было Model::firstOrFail(...), без всяких raw запросов и прочей нечести. (абстракция развращает).
Помню что для создания обычного GET resources/{id} нам требовалось написать raw запрос, контроллер, инициализировать Response объект... Когда в laravel из коробки это занимало 1 строчку тела метода.
Вы меня извините конечно, но это странный вопрос. Все равно что спрашивать, "а почему вы предпочтете Ладу Весту Четверке Жигулей?"
Codeigniter — это предания старины глубокой. Столько не живут. Этот фреймворк умер в незапамятные времена. И даже все попытки оживить этот хладный трупик — все эти Коханы, FuelPHP и иже с ними уже никто не помнит.
Несколько лет назад его отдали каким-то студентам для опытов, но использовать этот учебный проект в продакшене я бы поостерегся.
ну почему же странный вопрос - насколько знаю, симфони относительно большой и не самый простой фреймворк, который не всякому проекту на пользу пойдёт и много где будет "с перебором", для каких-то проектов вполне подойдут laravel, yii, slim, возможно, другие какие-то небольшие фреймворки.
Про старину глубокую и опыты для студентов - сложно судить, вот прямо сейчас посмотрел - CodeIgniter уже в 4ой версии , получается, что до сих пор какая-то база и пользователи у фрейворка есть и допускаю, что для несложных проектов он вполне может быть хорош.
Вы не поняли сказанное выше.
Для вас все фреймворки отличаются только "размером". Причем даже здесь вы попадаете пальцем в небо. Laravel, по-вашему — "небольшой" фреймворк.
При этом вы ставите на одну доску Ларавель и Yii, даты последних мажорных релизов которых отстоят друг от друга почти на 10 лет. Но для вас это никакой роли не играет. Интересный подход, но Даннинг с Крюгером его объясняют.
ну хорошо, давайте допустим, что для меня все фреймворки отличаются только размером - ничего страшного, и такие люди бывают.
Могли бы вы тогда объяснить - чем отличаются фреймворки, на какие параметры отличия нужно обращать внимания, как понять, что фреймворк "умер в незапамятные времена"?
Про даты последних мажорных релизов тоже - ну вот у CodeIgniter 10 января этого года был релиз версии 4.3 - вносит ли это некоторую реабилитацию для фреймворка или на это не стоит ориентироваться - но тогда на что стоит?
CodeIgniter был хорош 10 лет назад. Затем он умер. Сейчас его пытаются возродить из пепла, но нечего общего с прежним ламповым CI у современной версии нет. Так же большая проблема с комьюнити, большая часть которого ностальгирует по старым временам, когда трава была зеленее (я из их числа). Надоест профессору играться и CI исчезнет окончательно.
Yii тут все сложно, прям совсем.
Laravel - модно, стильно, молодежно. Идет в ногу со временем, создает популярные тренды.
А на что смотреть при выборе фреймворка, тут есть старый дедовский способ - идем на сайт с вакансиями и делаем фильтр по фреймворкам. Сразу станет понятнее, так как фирмы голосуют рублем.
спасибо, буду знать. Забавно, что с CodeIgniter я где-то лет 9 тому назад и сталкивался, мне он очень понравился, почему-то запомнился очень позитивно, но я не знал, что всё вот так пошло и сейчас "остатки былой славы"
п.с: что до голосования фирм - такое ощущение, что в плане бекенда безидейно выигрывает Лара, а в плане cms - Wordpress
...или Laravel, по нему полно специалистов разного уровня.
Какая-то путаница, сначала
Сайт - который будет общаться с хранилищем файлов (STORAGE) ~ files.website.com
потом
Для STORAGE, я тоже решил использовать PHP. Почему я не рассмотрел возможность сервисов для хранения файлов (объектного хранилища)? Напомню, я тут строю бюджетную систему и пытаюсь максимально сэкономить! А ещё есть пункты: 3.3/ 0.2/ 0.3/ 0.6 )
Так что же такое STORAGE если здесь же упоминаются сервисы вида Object Storage. Как я понял это Object Storage у Google или S3 у Amazon.
Если речь все таки о том, что бы хранить статику, то аргумент я тут строю бюджетную систему и пытаюсь максимально сэкономить будет не состоятельный. Object Storage будет стоить примерно 0 баксов, в рамках бесплатного лимита + не надо беспокоиться о бэкапах данных на виртуалке. Да и просто диск виртуалки большего объема для хранение статики будет стоит каких-то денег.
У меня Storage Самописный, и многое в нем заложено сразу из коробки
- Наложение водяных знаков на картинки
- Потоковая вывод изображения в нужном разрешении с оптимизацией по весу
- Разворачивание занимает 5 минут с мин настройками
- В нем планируется развивать защищенные зоны для хранения состояний у приложений
На мой взгляд это ненужный оверхед.
Наложение водяных знаков на картинки
Водяные знаки лучше наложить сразу при ресайзе и затем просто отдавать статику.
Потоковая вывод изображения в нужном разрешении с оптимизацией по весу
Не совсем понял что такое потоковый вывод изображений, но здесь я тоже приверженец позиции нарезать нужные размеры и всякие .webp при upload и отдавать уже готовые
- В нем планируется развивать защищенные зоны для хранения состояний у приложений
Это тоже не понял что такое
Мне почему-то кажется, что это забота о себе, а не о маклере. И оправдание про экономию бензина маклером - не убедительное. У них просто нет проблем для которых нужен сайт. А у вас есть :)
Во первых сайт рождает зависимые расходы. Собственное обучение, продвижение сайта, ежедневная актуализация. Инстаграм и каналы в мессенджерах потому и приобрели популярность, что ближе к людям и имеют меньше накладных расходов. В реалиях маклера - сайт имиджевая вещь. Маркетинг в вебе сейчас очень конкурентный и стоит в десятки раз дороже чем продвижение в локальных чатах
Для маклера (на мой взгляд) важно получить заявку. И не важно, по какому предложению или цене клиент пришел. Общаясь с клиентом лично, появляется возможность работать с его "слабостями" (время, усталость, терпение, персональные ожидания).
В Москве, агрегаторы типа Циан существует не потому, что маклерам сложно и они этого хотят. Скорее всего, они ненавидят Циан. А потому, что у агрегатов есть деньги и бизнес модель, чтобы подмять под себя рынок и самим выступать как маклер. И уже в рамках их объемов предложений - сайт отлично работает и окупает себя
Я не знаю, как вы продадите эту идею маклерам
Мне и не нужно продавать эту идею. Это сделает маркетолог. Для риелторов - это прежде всего экономия времени на размещение объектов. Отслеживание источников рекламы и оптимизация расходов на неё. В будующем - это интеграция с Telegram и автоматический постинг объектов в группы. У риелторов хватает проблем, но они не знают о них пока их не подсветишь.
Честно говоря, не вижу, как эта статья относится к хабу РНР. В ней много рассказывается про то, какой автор молодец, а также немного про базу данных и требования, но про РНР нет вообще ничего.
Я бы сказал что эта статья скорее подходит для хаба "Я пиарюсь".
Публикации
Как я сделал сайт для риелтора (маклера)