ThunderCat

1. Сервер я представляю как бэкенд разработку.

Это она и есть в чистом виде.

Метаюсь между JS (node.js), GO, и Java.

Странные метания, языки не сказать чтобы были сопоставимы. ИМХО:

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

Го будет норм, НО это довольно молодой язык, с одной стороны достаточно производительный (что не сказать чтобы как-то сильно его положительно выделяло в представленной задаче), с другой - спецов в него сильно меньше и поддержка выльется в боль с поиском сотрудников и достаточно дорогими спецами.

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

имею поверхностные знания по написанию кода на C, C++,

Тогда можно еще глянуть в сторону RUST, но опять же, оно молодое и дороговатое.

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

3. Стоит ли разбивать подобные проекты на микросервисы? То есть использовать брокер сообщений, который будет раскидывать сообщения от клиентов разным сервисам.

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

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

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

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

Подобное реализовано на flickr. Можете у них в коде поколупаться.

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

https://codepen.io/jo-asakura/pen/NWWrWj
https://web.archive.org/web/20160921141817/http://...

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

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

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

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

Как ни странно, но чего-то по типу дельфей под веб нету, ну, в плане wysiwyg IDE с возможностью склепать интерфейс + модули кода к ней. Интерфейс в виде хтмл блоков и яваскрипта для его "оживления" придется писать ручками. Благо код там не сложный, если не лезть глубоко в разработку интерактивных интерфейсов.

Бэкенд пишется на практически любом языке, но естественно есть группа более заточенных под веб, как то: Питон, пхп, C#, руби, яваскрипт... Практически каждый из них имеет 1-2 популярных фреймворков, включающих из коробки кучу готовых модулей для основных задач веб разработки. Скорее всего ближе к вашему предыдущему стеку будет C# ака ASP.NET Core + MySQL/SQL server, но вообще стоит для начала глянуть пару уроков по каждому, чтобы понять что будет удобнее сегодня конкретно вам.

Никак не могу понять куда смотреть.

Для таких случаев нужно логирование и проверки. Начать можно с file_exists(), is_file(), is_readable(), is_writable(), fileowner()...

1. Реально ли это сделать на HTML/CSS и JS?

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

2. Можно ли обойтись без WP?

Здесь он вам не понадобится

3. Куда будут сохраняться данные?

Зависит. Если общая статистика не нужна, то на такой примитив вполне хватит просто записи в редис/мемкеш, ну или в самом банальном случае в файл. В противном случае нужна бд. Данные для вывода на экран просто вытаскиваются по крону, скажем, каждые 5-10 секунд.

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

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

5. Есть ли уже готовые решения?

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

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

Да, это желательно, но не обязательно, если статистика не особо нужна.

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

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

За деньги https://directus.io/ например, типа админка SAAS...

Я всегда стараюсь приводить какую-то ясную аргументацию к конкретной предлагаемой технологии.
Мое мнение - берите вордпресс. При всей моей нелюбви к нему. На вырост - самое то.
Плюсы:
1) Это просто, базовый функционал вы и сами знаете, плагинов миллиард. Да, есть вопросы к качеству некоторых, но почти всегда есть альтернатива или в крайнем случае возможность написать/заказать нужный функционал.
2) Он поддерживает внятное чпу, которое легко перенести в более серьезный проект с нормальным роутингом.
3) Структура хранения хорошо известна, не идеальна, но нормально переносится.
4) Удобная админка. Не каждый разработчик заморачивается с админкой, так как "это же не фронтенд, сойдет".
5) По нему много спецов, продукт весьма популярный, так что в случае каких-то проблем легче найти спеца.
6) Это бесплатно, хотя ничего не мешает вам купить к нему стильный дизайн или крутой плагин за деньги.

Минусы:
1) Невысокая производительность на специфических задачах
2) Качество кода оставляет желать... Что не особо мешает функционалу
3) На больших нагрузках сильно проседает, но до этого еще дожить надо...

По перечисленным плюсам у него просто нет альтернатив. Как вариант - разработка чего-то своего, но это сразу деньги, и чаще всего просто выброшенные. Для мвп слишком жирно.
Dixi.

У нас есть дизайн сайта в фигме. Это корпоративный сайт.

Так все таки сайт или дизайн в фигме?

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

А кто будет самописать? И почему готовые системы не подходят?

Дизайн cms тоже готов.

Серьезный подход.

сделали даже визуализацию БД через mind map.

Оу, у вас нет разработчика, но зато нашелся датабэйс архитект, прикольно...

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

Из текста создается впечатление что ваш проект уже что-то делает, кроме как рисует фигмовые формочки... Это вводит в заблуждение.

1. С чего нам начинать разработку сайта, если большая часть контента создается через cms? С бэкенда или фронтенда?

Хинт: 99% сайтов создают практически весь контент из админки. Любой готовый цмс движок (вордпресс, октобер, да даже друпал) скорее всего полностью покроет ваши требования, кроме разве что дизайна админки (я хз можно ли там что-то кастомизировать малой кровью).

2. Какой стек технологий лучше использовать под нашу ситуацию для фронтенда?

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

3. Какой стек технологий лучше использовать под нашу ситуацию для бэкенда?

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

Если у вас есть ОЧЕНЬ специфичные штуки, которые вы не перечислили в вопросе - пишите, возможно под них действительно нужно писать самостоятельный продукт.

Как уже заметили коллеги - первое что нужно выяснить - что тормозит.

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

Что конкретно надо делать:
1) Взять за шкирку самого разбирающегося в коде (если таковой существует в проекте), и дать задание описать базовый стек вызовов, если это какой-то самопис, или сразу расставить код замера времени с метками в случае понятной архитектуры. Что то типа такого(класс - древний костыль, но работает, так что матом не ругаться):
Class Timer.php:

class Timer {

    static $start;
    static $end;
    static $marks = [];
    static $formats = [1=>''];

    static function init(){
        if(empty(self::$start)) self::$start = microtime(true);
    }

    static function setMark($markName = ''){
        $time = microtime(true);
        if($markName == '')$markName = $time;
        $data['name'] = $markName;
        $data['time'] = $time;
        $res['time'] = $time;
        if(count(self::$marks) > 1)$res['diff'] = $time - self::$marks[count(self::$marks)-2]['time'];
        else $res['diff'] = 0;
        $data['diff'] = $res['diff'];
        self::$marks[] = $data;
        return $res;
    }

    static function timeFormat($number,$format = ''){
        if(empty($format)) $format = 3;
        return number_format ($number,$format,'.','');
    }

    static function report(){
        self::$end = microtime(true);
        self::$marks['start'] = self::$start;
        self::$marks['end'] = self::$end;
        self::$marks['all_time'] =  self::$end - self::$start;
        if(!empty(self::$marks)) return self::$marks;
    }
}

In code:

\Timer::init()
//some code block 1
\Timer::setMark('after block 1');
//some code block 2
\Timer::setMark('after block 2');
...
//some code block n
\Timer::setMark('after block n');
//near end of code 
\Timer::setMark('end');
var_dump(\Timer::report());
exit;

2) Смотрите на блоки жрущие время, делите их до атомарных операций путем деления блоков пополам таймерами.
3) Смотрите что там происходит - оптимизируете*. И так по кругу.
4) Профит.

* Оптимизация
Запросы:
1) Смотреть план запроса (use explain, Luke!).
2) Расставить индексы которых явно не хватает
3) Смотреть не вызывается ли 50 запросов в цикле? Если да - выписать пенделя писавшему, затем переписать в 1 запрос с нормальным джоином.

Код:
Иногда запрос сложно оптимизировать, он вытаскивает много данных, хотя эти данные не часто обновляются. Такие запросы нужно кешировать, для чего используют быстрые ин-мемори хранилища типа редис или мемкеш. В крайнем случае в файлах...
Чаще всего код тормозит на регулярках, хотя "хороший" программист может придумать и более креативные способы погреть процессор.

Что нужно сделать обязательно кроме тестов и как тогда лучше спрашивать с разработчиков, если они предлагают размытые предложения? Хочется понять в какую сторону копать

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

PS: Кстати, сервер может банально не выдерживать наплыв сетевых соединений, пните адимна, пусть глянет логи.

PPS:

достаточно 2000-4000 человек, заходящих в течение 20 минут на сайт

это равномерные 3-4 рпс, ну или пусть в пике 50 рпс, должно держать даже на несложной конфигурации... Копайте код.

• регистрация/авторизация пользователей;
• добавление/удаление записей;
• формирование отчета в формате docx.

практически все что перечислено в качестве инструментов - хватает или избыточно.

1) Нужна ли асинхронность, исходя из функций приложения?

Нет, тем более для подхода через REST API.

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

Как самый простой вариант смотрится лара + 4 готовых модуля, 2 из которых вроде даже идут из коробки, остальные добиваются 1 командой композер инсталл %пакетнейм%.

3) Исходя из функций приложения, это будет SPA (одностраничное приложение) или PWA (многостраничное приложение)?

Это не противопоставление, это вообще не взаимосопоставимые технологии. PWA может быть SPA, может не быть... PWA это вообще не про "многостраничность".

Остальное не скажу, так как не в теме.