Начнём с того, что я не разработчик, а системный администратор. Умею поднимать LAMP и Redmine
Знаю HTML, CSS, JS, PHP и много других страшных слов.
Есть в голове одна задумка. Точнее, задумок куча, с реализацией проблемы.
Хотя одну недавно реализовал. Скрипт цитатника (подобного башоргу) не купил, а написал сам.
Но следующий проект слишком сложен. Скажем так, пользователи, товары и прочее - это сущности.
Так вот, в MariaDB (форк MySQL) в базе данных проекта получается никак не менее семи сущностей (взаимосвязанных таблиц). А ведь ещё надо реализовать CRUD, права доступа... а в перспективе - и превратить сайт в приложение для Android.
Чтобы сильно не распыляться, думаю авторизовывать пользователей через VK (приложение только для России).
Проблема в том, что опыта в построении (и уж тем более реализации) проектов такого уровня у меня нет. Ещё большая сложность в том, что я получаюсь единственным разработчиком, ибо платить кому-то за свои хотелки нечем, а энтузиасты-бессеребренники вряд ли найдутся.
Пока думаю начать реализовывать BACKEND ибо если будет связанный набор данных, отобразить его на фронтэнде будет куда как проще.
Всякие SCRUM и Agile для меня - тёмный лес. Одно понятно - проект надо сначала разбить на этапы. Хотя есть нюансы, которые пока и мне самому не до конца понятны. В частности идея создания временных или постоянных групповых чатов. С одной стороны есть VK API, с другой стороны имеет смысл реализовать подобное на своей стороне, поскольку сообщения в этих чатах будут весьма формализованными.
Ну и законодательство учесть надо. Типа если я сам буду брать у клиентов деньги и класть на счёт, с которого они будут рассчитываться за покупки - не будет ли это считаться оказанием банковских услуг и не будет ли из-за этого проблем с налоговой? Пока я думаю обойтись без этого - типа я только предоставляю интерфейс. Продавцы им смогут пользоваться за денежку, а покупатели бесплатно. Да, по сути это будет маркетплейс, но с ограничениями на тип товаров.
Начерно бизнес-процессы уже выстроены, но... "гладко было на бумаге..."
Соответственно, писать (и заполнять) БД, выкладывать фото товаров можно уже сейчас (они типовые),
а вот прочие тонкости хотелось бы предусмотреть заранее.
Я уже начинал (и периодически бросал) этот проект. Не хотелось бы его забрасывать в очередной раз.
Умные слова не нужны, как и готовые фреймворки и конструкторы сайтов.
Нужно сесть и сделать, и вопросы задавать не общие а конкретные.
Да по законодательству, вы не имеете права хранить деньги пользователей и вообще заниматься их приемом, только платежные системы и банки это могут... Но если копнуть глубже проблема не в хранении а в передачи денег между пользователями, государство желает это контролировать.
По технической части, нужно решить глобально, какой тип генерации html будет использован - на стороне бакэнда (скрипты в браузере использоваться не будут), или на стороне клиентского браузера на javascript (его ещё называют single page application). Первый вариант хорош для поисковых систем (если проект основан на контенте и особенностях продвижения), подходит для простых дизайнов (без сложных анимаций и художественной стилистики), даёт слегка повышенную нагрузку на сервер бакэнда. Второй вариант всю работу, связанную с дизайном и отображением переносит на клиента, сервера это собственно бизнес логика и раздача статичных файлов, очень эффективная нагрузка на бакэнд, но поисковые системы плохо такие анализируют (или совсем никак, ведь для этого нужен робот-браузер), и ограничивает выбор языка программирования для фронтэнда тем что даёт браузер. Обычно используют смесь подходов, но мне кажется по глупости.
Потом хотел сделать сайт и даже попытался сделать адаптивную вёрстку для товаров
Думаю, html будет отдаваться или в чистом виде, или в PHP - поскольку бэкенд на PHP будет отдавать данные сущностей в JSON и для правильной отрисовки понадобится fetch (или более старый XMLhttpRequest). Думаю, получать данные от PHP и тут же закидывать их обратно в PHP - не совсем логично, а делать напрямую - значит усложнять веб-дизайн.
Соблазнительно, конечно, запилить всё на Yii2, но я пока в нём не слишком хорошо разбираюсь, так что не рискну. Да и ИМХО, проект тогда перетяжелённым окажется.
Опять же, если разделять фронт и бэк, будет проще проверять данные. ИМХО, конечно.
Средний
