Необходимо реализовать фронт проекта, но непонятно как к нему подступится
Суть проекта в двух словах:
сделать тоже самое что и cawemo.com но в новой “упаковке” и с большим дополнениями.
Суть дополнений: большие процессы состоят из маленьких, те в свою очередь из еще поменьше. Часто маленькие процессы в схемах используются повторно в других больших схемах, то бишь для проекта (куча больших схем) они глобальные, следовательно их нужно переиспользовать.
Все как в программирование:)
Для этого нужно реализовать:
репозитарий глобальных под процессов
конвертацию из локальных в глобальные
usage list (места на схеме где глобальные процессы были использованы)
Это и будет отличительной фишкой, ну и плюс конечно другие плюхи:
версионность
комментарии
структурированность процессов
(этого вообще нигде нет, и это реально проблема, как будто у всех не по 100-200 процессов а по 1-2).
На чем писать (фреймворк), стоит ли переиспользовать bpmn.io (хотя бы частично)
Где искать хорошего (senior js), а может кто то и посоветует кого то конкретного, можно совмещать, делать в свободное время (все обсуждаемо)
Как лучше подойти к разработке:
сверстать весь фронт, потом натянуть на бек
делать частями, сделал кусок фронта и бека, переходим к следующему
P.S.
Бек будет на PHP + MySQL, разработчик есть
Готов оплатить консультацию опытного js разработчика, особенно если есть релевантный опыт
По срокам не горит
Да стоит. Бессмысленно писать подобное решение самостоятельно: уйдет куча времени и ресурсов. Но только для визуального представления, возможно для взаимодействия с пользователем. Но какой бы ни была модель данных этого фреймверка, нужно написать свою модель (потому что та модель может быть концептуально несовместимой с планами развития продукта).
Фреймверк для GUI-я вообще не принципиален. На чем будет удобно писать человеку - пусть на том и пишет. Как язык typescript более лучшая идея для этого проекта чем js. Но тайпскриптер может не попасться.
Зависит от стратегии продвижения. Если есть клиент - сделать первую версию под клиента и продолжать итерировать. Если клиента нет - сделать MVP, и итерировать в зависимости от обратной связи тех кто будет первыми пользователями.
В любом случае нужно понять:
Какая функциональность есть обязательная, какая - второстепенная. Чем больше тратишь времени на второстепенную функциональность, тем сильнее откладываешь выход продукта на рынок, тем позже получаешь обратную связь, тем больше вкладываешь ресурсов (денег-времени) без понимания на сколько они приносят пользы.
Какие есть варианты развития приложения (версионность, например) и их вероятности. Зная их, можно избежать будущих несовместимостей клиент-серверного API и ошибок при проектировании структур данных.
Только так.
Без понятия. Но могу помочь публично обсудить мысли кандидатов которых ты найдешь. Чтобы другие могли подсмотреть/подсказать/начать дискуссию.
Готов ответить, углубить пояснения на дополнительные вопросы по поводу вышесказанного.