Как мне их правильно соединить?Во первых - зачем? Смысл разноса api и приложения в том что бэк работает одинаково со всеми запросами (не особо важно кто и как их дергает, лишь бы права позволяли), а фронт не зависит от бэка в представлении. По этому фронт пишется как морда на каком-нибудь реакте, который от бэкенда получает данные по запросу. Нужно авторизоваться - стучишся в эндпоинт авторизации, отдаешь креденшелы, получаешь токен. Нужно список юзеров - берешь доку по апи, стучишся с нужным пэйлоадом на эндпоинт, получаешь жсон списка, из него рисуешь что хочешь...
Или frontend и backend размещены разными программами?что-то мне подсказывает что наверное вы рановато по знаниям взялись за задачу...
Можете посоветовать как к этому подойти? Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать? Мне кажется, что это возможно, потому что Авито был до того как появился реакт, как-то же это сделалиПочти любой современный сайт состоит из 2 основных частей: Фронтэнда и бэкэнда. Фронт - то что отображается в окне браузера, бэк - серверная часть, отвечающая за чтение, изменение и сохранение данных, которые можно вывести для клиента в любой удобной форме. По этому для реализации вашего проекта понадобятся знания не только верстки и js, нужно будет и разобраться с серверной частью, которая обычно состоит из движка на каком-то языке, подходящем для веб разработки (PHP, Pyton, Java, JS...) и базы данных, где будут храниться собственно данные о пользователях, объявлениях, просмотрах и т.д.
Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать?А искали?
нужно сделать передачу данных из формы на сайте напрямую в TXT файлПонадобится все же какой-то серверный код, который что-то будет делать на стороне сервера с пришедшими данными. Можно тот же жаваскрипт, если сервер поддерживает ноду.
и чтобы то что передалось с сайта в txt файл через к примеру час автоматически удалилосьАвтоматически это как? Любая "автоматически" работающая программа имеет какой-то код, определяющий что и когда делать. Вариантов что вы там задумали миллиард, как определитесь с конкретным стеком/алгоритмом - перейдете к этому вопросу.
Может уже существуют готовые решение такого ? Очень ищуНаверняка, чего только юные падаваны не пишут в порыве творческого припадка, просто большинство стесняется выкладывать такой откровенный бред, а кто не стесняется видимо еще не знает как выкладывать в общий доступ скрипты в 4 строчки. Так что пишите, выкладывайте, первым будете )
1. Сервер я представляю как бэкенд разработку.Это она и есть в чистом виде.
Метаюсь между JS (node.js), GO, и Java.Странные метания, языки не сказать чтобы были сопоставимы. ИМХО:
имею поверхностные знания по написанию кода на C, C++,Тогда можно еще глянуть в сторону RUST, но опять же, оно молодое и дороговатое.
3. Стоит ли разбивать подобные проекты на микросервисы? То есть использовать брокер сообщений, который будет раскидывать сообщения от клиентов разным сервисам.Зависит, для микросервисов архитектура создает еще один дополнительный уровень сложности, а при предполагаемом небольшом (до сотен тысяч) клиентов особой нагрузки вроде быть не должно. Проще построить монолит и, если возникает нагрузка на определенный внутренний функционал, выносить его в сервис, там есть нюансы и порог с которого все это имеет смысл, так что начинать достаточно типовой проект стоит с монолита в любом случае.
в куках храню токен и вот задался я таким вопросом, а как запретить использовать этот токен на других устройствах? То есть, что я имею ввиду. Вот есть скажем 2 пк, на одном Вы авторизовались, открыли cookies, скопировали токен и на другом пк его вставили и таким образом вы зашли в аккаунт без авторизации.В чем проблема? Так работает вся система куки-зависимых данных (например сессии). Так как куки является приватной информацией в рамках сессии, данные в ней так же считаются приватными и по умолчанию недоступными третьим лицам. По этому все страдания на тему "ой, можно же что-то вытащить и вставить это не безопасно" и прочие страдания юных специалистов по безопасности можно смело взять и выкинуть в психологическую мусорку.
В этом куске кода критическая переменная это tokens. При нажатии на кнопку start со стороны клиента у пользователя отнимается один токен и кол-во общих токенов отправляется в бдНе надо тупить. Раз токен это критичные данные, то никаких "со стороны клиента" быть не должно. Нажат старт - на сервер отправилось "старт пошел", из данных в бд вычитается/прибавляется значение, обратно отсылается что в итоге получилось. С остальным так же - на сервер отправляется событие, а сервер считает чего куда прибавлять и возвращает результат на фронт.
по итогу генерируется фото футболки с теми параметрами, которые он выбрал?Называется "влажные фантазии". Обычно на маркетплейсах за подобный функционал отвечает фильтрация, а не меню. Никакой генерации обычно не используется, просто фото всех доступных вариантов есть в виде картинок, а параметры перечислены в бд.
Проблема в том, что времени на разработку сайта с нуля нет, поэтому нужны шаблоны или готовые решения, которые я мог бы в дальнейшем переделать под свои (учебные) нужды.Готовые решения сложнее модифицировать под свои нужды, нежели писать что-то с нуля. Кроме того, писать "с нуля" сегодня практически исчезающая практика. Все пользуются фреймворками, функционал которых "из коробки" уже достаточно широк, а за счет модулей предоставляет почти любой функционал.
Мне сказали, что можно использовать готовые отечественные (или другие, но с открытым кодом) CMS- или CRM-решения, но опыта в этой сфере у меня почти нет, поэтому в том, что выбирать и как подключать, возникли проблемы.Самые примитивные в плане настройки - 1С битрикс ("отечественная") и Вордпресс, если уж с их установкой и настройкой будут проблемы, то лучше сразу переориентироваться в сторону работы кайлом и кувалдой...
Никак не могу понять куда смотреть.Для таких случаев нужно логирование и проверки. Начать можно с file_exists(), is_file(), is_readable(), is_writable(), fileowner()...
1. Реально ли это сделать на HTML/CSS и JS?Без бэкенда не получится организовать общий сбор и обработку данных, так что если бэкенд делать на нодеЖС - то да, если же речь чисто о фронтенде - нет.
2. Можно ли обойтись без WP?Здесь он вам не понадобится
3. Куда будут сохраняться данные?Зависит. Если общая статистика не нужна, то на такой примитив вполне хватит просто записи в редис/мемкеш, ну или в самом банальном случае в файл. В противном случае нужна бд. Данные для вывода на экран просто вытаскиваются по крону, скажем, каждые 5-10 секунд.
4. Можно ли сделать что бы у оператора была своя статистика своего рабочего места?Можно, но для этого уже нужны минимальные заморочки с аккаунтами и тут уже без базы будет как минимум сложно и странно.
5. Есть ли уже готовые решения?Если и есть, то они вряд ли где-то выложены в публичный доступ, слишком специфичная задача. Не сложная, но не сказать чтобы распространенная.
1. Я так понимаю что у каждого оператора будет своя страница, как то же программа должна понимать что эти данные пришли от пользователя 1.Да, это желательно, но не обязательно, если статистика не особо нужна.
или можно просто с эти не заморачиваться и не делать отдельные учетки. но тогда если все одновременно нажмут отправить данные что в итоге отобразиться?Во первых не бывает "одновременно", все равно будут задержки на клик, на сеть, на реакцию браузера и т.д., мало вероятно но более реально что на сервер придут данные одновременно, но для этого существует очередь обработки. Если запись будет вестись в бд, то все запишется по порядку обработки. Впрочем, с другими хранилищами тоже проблем не должно быть.