Какой набор пакетов использовать, чтобы реализовать простой веб-сайт?

Question

[anna_makeenko]

Нужно по быстрому написать простой сайт без использования фреймворков (тестовое задание). Хочу использовать готовые пакеты. Подскажите, пожалуйста, хорошие пакеты для маршрутизации (роуты, контроллеры), аутентификации пользователя и работы с БД

Comments

[Maxim Colesnic]

Хорошая вещь https://github.com/symfony/routing

Answer 1

[Дмитрий Энтелис]

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

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

Отдельный вопрос - почему вы вдруг хотите использовать внешние пакеты, если у вас нет уже проверенных с чем вы работали ранее?

По списку:
1. Роутер: https://github.com/search?q=php+router
2. Аутентификация пользователей - зачем тут какой-то пакет??
3. ORM - использование ORM в живом проекте очень холиварно. Скорее всего смысл задания - проверить еще и ваше умение писать запросы руками.

Comments

[xmoonlight]

Я лучше и не смог бы дать ответ!
Респект!

[anna_makeenko]

Т.е. вы считаете, что в 2020 году изобретать велосипеды и писать приложение на PHP не используя composer и готовые библиотеки - это нормально?

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

Если бы хотели проверить ваше умение гуглить готовое - задание звучало бы "собрать из готовых библиотек".

Мне кажется одно другому не мешает. Или качественно собрать собственный микрофреймворк может каждый?

P.S. Задание не для Junior, в описании сказано, что нельзя использовать готовые фреймворки, но не сказано, что нельзя использовать отдельные пакеты.

[Дмитрий Энтелис]

anna_makeenko,

вы считаете, что в 2020 году изобретать велосипеды и писать приложение на PHP не используя composer и готовые библиотеки - это нормально?

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

Мне кажется одно другому не мешает. Или качественно собрать собственный микрофреймворк может каждый?

Как вы сами написали - это тестовое задание, а не реальный проект.
Написанный с нуля код расскажет гораздо больше о кандидате, чем куча копипаста.
Вот зацепили вы роутер, orm, какой-то oauth модуль.
А что остается оценивать интервьюверу? 10 строчек в контроллере где все это собирается в одно целое?

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

[anna_makeenko]

А что остается оценивать интервьюверу? 10 строчек в контроллере где все это собирается в одно целое?

Способность быстро решить задачу с учетом всех требований и стандартов.

[Дмитрий Энтелис]

anna_makeenko,

Задание не для Junior, в описании сказано, что нельзя использовать готовые фреймворки, но не сказано, что нельзя использовать отдельные пакеты.

Значит этот вопрос стоило задать тому кто давал задание. В моем понимании запрет на фреймворки без запрета на пакеты - бесмысленный.
Тот же симфони попакетно можно целиком практически утащить - какой смысл тогда?

Способность быстро решить задачу с учетом всех требований

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

Answer 2

[index0h]

Раз у вас с этим трдности - боюсь вы не прошли.
Что касается пакетов:

1. symfony/routing
   
2. symfony/security-guard
   
3. doctrine/orm
   

Comments

[anna_makeenko]

Раз у вас с этим трдности - боюсь вы не прошли.

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

Кажется компоненты Symfony сильно завязаны между собой. Так же Symfony больше не является членом PHP-FIG, а значит может не придерживаться PSR, что немаловажно при использовании пакетов вне экосистемы Symfony.

[index0h]

anna_makeenko, компоненты симфони как раз наоборот очень слабо связаны. По этой причине их можно встретить в куче систем и фремворков.

Что касается psr - да, придерживаются не вообще всех, но ключевых. На самом деле редко кто это делает в полной мере.

Если вы уже используете форейморки / микро фреймворки - зачем задаете вопрос?)) Берите их компоненты, что вам
нравятся и вперед.

[Developer]

Раз у вас с этим трдности - боюсь вы не прошли.

Куда не прошли?

[Сергей Горностаев]

Developer, у автора вопроса тестовое задание. Тест не прошёл.

[anna_makeenko]

index0h, а как понять ключевой он или нет? PSR 7/ PSR 15, например, ключевые?

[Дмитрий Энтелис]

anna_makeenko, если вы до сих пор верите что в коммерческих проектах все по PSR - вас ждет дикое разочарование жизнью.

[anna_makeenko]

Дмитрий Энтелис, "коммерческий" - понятие растяжимое, в данном случае. Symfony - коммерческий проект?

Хотелось бы, чтобы была возможность заменить какой-либо пакет аналогичным и чтобы это не коснулось приложения в целом. Symfony не очень подходит, поскольку они теперь не соблюдают PSR.

[Дмитрий Энтелис]

anna_makeenko
Коммерческий это абсолютно конкретное понятие: если ваш код приносит деньги он коммерческий.
Symfony сам по себе это опенсорс for fun.

[index0h]

anna_makeenko, с моей точки зрения ключевые - форматирование / автозагрузка / логгирование.
7ой - такое, можно использовать, можно нет.
15ый - со всей силы не ключевой.

[BoShurik]

anna_makeenko,

поскольку они теперь не соблюдают PSR

Это неверно. Они соблюдают PSR, если могут.
PSR-7 они не соблюли (при этом были на тот момент в составе FIG), но добавили bridge.
Новый http-client от Symfony так же поддерживает PSR-18 через декоратор, хотя на тот момент они уже покинули FIG. Тут надо отметить, что если захотите использовать PSR-18, то лишитесь встроенной асинхронности.

[anna_makeenko]

BoShurik, да, я понимаю что можно использовать бридж, но есть другие компоненты (например компоненты Zend), которые поддерживают PSR 7 из коробки, поэтому, непонятно зачем нужны эти танцы.

[BoShurik]

anna_makeenko,

зачем нужны эти танцы.

symfony/http-client гораздо более функциональный, чем тот, что предлагается в PSR-18. Хотя бы поэтому.

Если уж брать выход из FIG, как решающий фактор, обратите внимание, что Guzzle (самый популярный http-client) тоже вышли от туда

[anna_makeenko]

BoShurik, речь идет о микрофреймворке для обработки запросов пользователя.

Т.е. я могу установить роутер с поддержкой PSR 7 (например aura), соответственно нужен компонент HTTP с поддержкой PSR-7 - далее я смогу заменить любой из них без вмешательства в свое приложение. Если пакет не следует PSR - начинаются танцы (хорошо, что в Symfony есть бридж, а если его не будет?). Если мне нужна другая функциональность - я подключу дополнительный пакет.

[index0h]

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

[anna_makeenko]

index0h, нет, но как это касается того, что написано выше?

[index0h]

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

[anna_makeenko]

конечно касается.

Как?

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

Что я и делаю.

Я не говорю об обновлении зависимостей, а об переезде например с симфони на зенд, или еще что-то.

Об этом речь не идет

[index0h]

anna_makeenko

Как?

Часть стандартов PSR, определяющих общие интерфейсы, тот же PSR-7 например, дают вам возможность отвязаться от конкретного вендора, как следствие ваш код становится более лучше переносимым. Это замечательно, но задача перехода от одного вендора к другому возникает очень редко, как минимум потому, что она обычно очень затратная по времени.
И вот тут возникает два очень важных момента:
1. Подобные стандарты PSR очень общные, вендорные решения часто имеют больше функциональности.
2. И PSR и вендорные решения устаревают, вам в любом случае придется тратить время на поддержку что первого, что второго. Разница лишь в том, что с некоторыми PSR-ами вы более ограничены.

Answer 3

[Philipp]

Для того, чтобы создать простой веб-сайт, вам не нужен PHP.
Возьмите старый добрый HTML и сделайте 2-3 странички в редакторе. Готово.

Comments

[anna_makeenko]

Так себе ответ. Написано же, что нужна аутентификация и возможность работы с БД.

[Philipp]

anna_makeenko, когда говорят про простой сайт, то о базах речи не идет. А аутентификацию вполне себе можно реализовать используя Basic Authentication.

[anna_makeenko]

Philipp, серьезно? А сложный сайт это когда есть база данных? Ясненько.

[Philipp]

anna_makeenko, набирайтесь опыта.
Как задавать вопросы

[anna_makeenko]

Philipp, походу опыт нужен именно Вам, особенно учитывая что сайт с БД - это для Вас "сложный сайт" :D

[Philipp]

anna_makeenko, я делал сложные сайты даже без баз данных.

[anna_makeenko]

Philipp, молодец :)