Comments 69
Также у каждого фрагмента может быть свой менеджер состояния (MobX, Redux, VueX сторы).
Задумался. Загрустил.
Нет, конечно срочно ваять MVP таким манером, наверное, можно, но…
Можно внутри сервиса реализовать опрос хаба Websocket в бэке.
Возможно, было бы уместно реализовать через него паттерн «Publisher — Subscriber» для оповещения фронтовых компонентах о событиях в бэке. Возможно, паблишера событий выгоднее будет реализовать отдельно от данного сервиса и импортировать в него как стороннюю сущность. Сервис будет чем-то вроде хаба / шлюза для интеграции с бэком.
Таким путем данный сервис может дорасти до статуса Service Worker (кэширующая прокся между браузером и бэком). Это если в будущем понадобится нарастить мышечную массу в сервисе.
Хочется повыносить в сервис такой весь инфраструктурный код, вроде клиента Websocket.
С фронта через Websocket с определенным периодом будут отправляться запросы на получения текущего статуса фоновоой обработки данных
Извините, а зачем через сокеты запрашивать что-то с фронта, если бэк сам может послать уведомление об окончании обработки?
То что выглядит как посылка от сервера на ваш компьютер скорее всего реализуется одним из двух способов:
1. По принципу перманентного коннекта по TCP/IP, когда пайп удерживается непрерывной пересылкой проверяющих пакетов туда-сюда-обратно (вернее не удерживается, а проверяется не оборвалось ли подключение).
2. Принимающая сторона постоянно спрашивает, есть ли для нее новое письмецо.
Так или иначе, принимающая сторона выспрашивает у сервера новые сообщения.
Какой способ эффективнее и надежнее, надо профилировать и проверять.
Я предпочитаю явное поведение и более простую реализацию (в смысле контроля над поведением). Но в случае с websocket особой разницы нет.
Вы либо спрашиваете сами с достаточно коротким периодом (скажем в 3 секунды), либо этот опрос делает за вас криво написанная либа для первого SignalR (с какой частотой она опрос сервера делает не выяснял).
Есть подозрение, что у вас бэк на php написан или типа того, который из коробки не держит постоянные соединения и не может вам обеспечить такой функционал. Но библиотеки типа socket.io умеют понимать, когда нормально сокетное соединение не поддерживаются и переходят в режим постоянных запросов-ответов (ping-pong). Вероятно у вас как раз так и работает. Но это не значит, что сервер не умеет отправлять принудительно сообщения в браузер.
а то, что постоянно шлются запросы говорит о проблеме в настройке веб сервера.
Таки да. Когда я проксирую через nginx, тоже приходится дополнительно конфиг дописывать, что-то типа такого:
location /api/ {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 36000;
rewrite ^/api(.+) $1 break;
proxy_pass http://localhost:4000;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}- Статья не про SignalR. Детали реализации общения через WebSocket для целей статьи несущественны.
- Подробно в подкапотных деталях работы SignalR и Websocket в целом копатья не доводилось. Согласно диаграммам в этом пособии и представлениям о сетях коммуникаций видится следующее:
а) Клиентская либа (SignalR напр.) инициирует Persistent Connection. Как это работает? Оба конца должны быть уверены, что коннекшен еще жив. Проверить это можно отправкой короткой датаграммы с неким периодом. Об этом я и писал.
б) Пока коннекшен жив мы можем слать данные туда-сюда и уже не важно чья инициатива начать отправку (событие в сервере или браузер клиента).
В случае широковещательного сообщения все просто — по событию на сервере вызываем у хаба отправку сообщений всем клиентам (можно отправить нотификацию, что все клиенты должны перезапросить свои статусы). Если же мы хотим пушнуть сообщение для конкретного клиента, то надо всех клиентов как-то идентифицировать. Иначе после широковещательного сообщения бестолковых перезапросов статуса от всех подключенных клиентов может быть больше, чем периодические запросы от одного клиента.
Тут еще играет роль то, что мы имеем ферму инстансов серверов с балансировкой. В результате техническая сложность реализации подхода с пушем события растет сильно.
Для MVP было решено не переусложнять решение (для первого опыта с SignalR лучше попроще было сделать). SignalR Hub в итоге работает подобно WebAPI Controller, но транзакции значительно эффективнее. Переделать такое решение на нормальную событийную коммуникацию не очень сложно.
Детали реализации общения через WebSocket для целей статьи несущественны.
Но тогда вообще лучше про WS ничего не говорить. А то получается «Возьмем кое-что и не будем использовать его как надо».
Оба конца должны быть уверены, что коннекшен еще жив.
В том-то и дело, что в случае использования WS оба уверены. На обеих сторонах есть события on[connect,disconnect] и т.п. И если где-то отвалилось соединение, вторая сторона обязательно об этом узнает.
то надо всех клиентов как-то идентифицировать
Это уже вопрос реализации. В любом случае, на это есть средства. Когда вы на сервере принимаете новый WS-коннект, вы можете идентифицировать пользователя (как именно идентификация будет выполняться — это уже вопрос конечного проекта). А когда хотите отправить кому-то персонально сообщение, ищете уже в общем пуле соединений те, которые персонализированы по нужному пользователю.
Но у меня делается иначе: у меня для разных сущностей есть разные подписки, например «Подписываюсь на сообщения, созданные для меня или в группах, где я участвую». И когда создается сущность, соответствующая этим критериям, я получаю в браузер уведомление.
В том-то и дело, что в случае использования WS оба уверены. На обеих сторонах есть события on[connect,disconnect] и т.п
Вы меня недопонял, кмк. На низком уровне как реализован Persistent Connection? Как две программы на двух разных компьютерах определяют, что коннекшен ещё жив?
Все мои комментарии были о том, как технически это может быть реализовано.
WS — это же не UDP.
Мне кажется интересным разобраться в тех. деталях коннекшена через WS и конкретно SignalR.
И кстати вам должно быть известно, что SignalR перед установкой коннекта пробует несколько протоколов (в зависимости от поддержки на стороне сервера). Оттого может зависеть, какой подход выгоднее.
Вы меня недопонял, кмк. На низком уровне как реализован Persistent Connection? Как две программы на двух разных компьютерах определяют, что коннекшен ещё жив?
Я не уверен, правильно ли понял вопрос, но обычно это реализуют браузеры
https://html.spec.whatwg.org/multipage/web-sockets.html#ping-and-pong-frames
Кроме того у каждого вебсокетного соединения есть свой уникальный id, что лучше подойдет для вышеописанного случая: нет необходимости сообщать всем, на какой стадии идет парсинг или импорт.
Так или иначе, принимающая сторона выспрашивает у сервера новые сообщения.
В случае websocket нет, сервер сам может отослать сообщение клиенту, так как это обычное tcp/ip соединение.
Просто зачем тогда вам вообще websocket? преимущество его именно в двусторонней связи. Вы таким методом можете с успехом использовать обычный http.
Но в случае с websocket особой разницы нет.
Как раз есть, в вашем случае вы подключили websocket и используете его как http.
либо этот опрос делает за вас криво написанная либа для первого SignalR
Либа здесь не причем, те сообщения, которые вы можете видеть в логе, обычная реализация протокола браузером, и это как раз проверяющие пакеты туда-сюда-обратно. Даже первый SignalR использует доступный способ передачи в данном браузере, и если WebSocket реализован, будет использовать его, и вся имплементация лежит на браузере. Никакого опроса на новые сообщения в SignalR при использовании WebSocket я не видел.
прочитал статью, во первых хотелось бы сказать спасибо за труд, но есть некоторые вещи которые мне кажутся не очень логичными.
- Вы начинаете показывать альфа версию, когда уже готов бэк, если предположения фронта были не правильные или требуются переделки, то работа по бэку была в стол, почему бы не показывать фронт когда он на тестовых данных? и собирая фидбэк вносить корректировки.
- У вас есть спецификация (я не о формате ответов от апи) по фронту и e2e тесты, смысл держать спеку, ведь e2e тесты покажут насколько фронт соответствует тому что ожидается, я бы предложил делать e2e тесты раньше фиксируя ожидаемое поведение и фиксируя спеку, прошел e2e соответствуешь спеке.
- Ну и самое забавное, вы предлагаете разбивать задачи на большое число веток (ничего против веток не имею и git с ними справится) но ваш профит в том что придется решать меньше конфликтов, но теперь представьте пока вы фичу делаете в мастер влили другую фитчу(другая команда) и возникли конфликты (это нормально), вы делаете rebase или merge для import ветки разрешаете их, потом другие разработчики вливают к себе import ветку и тд, а теперь другая ситуация, вы собрали ветку import влили все ветки фронта и бэка и возникли конфликты при вливание вашей мега большой ветки в мастер (или дев) и теперь все участники должны быть чтобы по решать конфликты (причем двух больших веток что вливали).
Я бы предложил отдельные ветки разработчиков с частями фитчи import, сразу вливать в мастер (или дев, она же не релизит это). - Прочитал про количество ролей что ожидается использовать: фронтовики, бэкендеры, редактор спецификации, мейнтенеры ветки фичи, уверены что последние 2 нужны? может я еще кого то забыл.
Есть еще нюансы которые лично у меня вызывают вопросы, но хотелось бы иногда сказать что далеко не все процессы можно запускать параллельно и то что не всегда процесс выполняемый параллельно быстрее последовательного выполнения.
Мои любимый анегдот в тему паралельности, менеджер думает что если одна девушка рожает ребенка за девять месяцев, то девять девушек сделают ребенка за один месяц.
- Последние две роли — эпизодические. Мэйнейнер сам может быть девелопером части функционала (ему же не надо постоянно сидеть без дела и ждать чужих ПР). То же и с редактором спецификаций. Просто дано конкретное имя для временной функции.
- Не уверен, что смогу ответить на все, т.к. без примера детали проблемы трудно понять.
3.1 Если мы пилим новую фичу, то с очень маленькой вероятностью будет конфликт (физически под новую фичу отводится новый каталог). Конфликт возможен, если будет запрет на глубину вложенности субкомпонентов реакт и потребуется создать каталог для субкомпонента на одном уровне с компонентами от других команд. Эта проблема может быть решена именованием субкомпонента (например, вместо PageFooter назвать компонент ImportPageFooter). Просто избежать коллизии имен.
потом другие разработчики вливают к себе import ветку и тд
Не понятно каких конкретно вы имеете в виду разработчиков… Другой команды или моей же.
В любом случае, import-dev ребейзится или мержится в мастер по завершению работы над MVP. После аппрува ПР и вливания в мастер все временные ветки моей команды могут быть спокойно удалены. Конфликты с другими командами перед мержем в мастер пофикшены и ПР принят. Дальше начинается обычная поддержка (багофиксы и тп). Разработчики из моей команды просто переключаются на мастер.
Я бы предложил отдельные ветки разработчиков с частями фитчи import, сразу вливать в мастер (или дев, она же не релизит это).
Это понятный подход. И с вами я согласен в том смысле, что он проще для девелоперов. Но когда разные части делаются не в синхроне и из мастера автоматом изменения доставляются на стейдж, мы получим таким путем сбой доставки в прод. На стейдже от разных команд постоянно будут недоделанные изменения, которые нельзя показывать пользователю.
Если б не было стейджа, где встречаются разные команды с разными циклами разработки, то было бы ок.
e2e на самом деле у нас и пишутся в параллели, но идет это дело долго и поэтому все равно они будут готовы позже готовности прототипа UI.
Именно так и описано как вы написали. Читайте в разделе про CI последний абзац.
e2e на самом деле у нас и пишутся в параллели, но идет это дело долго и поэтому все равно они будут готовы позже готовности прототипа UI.
получается e2e остается для того чтобы обнаруживать регресс?
Не понятно каких конкретно вы имеете в виду разработчиков
Вы начали сприпт, у вас большая команда и импорт данных это одна из задач, есть и другие которые будут делаться другими людьми (или в том числе и этими же), так получилось что другие задачи сделали раньше чем импорт, разработчикам работающим над импортом придется учитывать и влитые эти задачи и при merge или rebase могут возникнуть конфликты, далее разработчики что не влили в ветку импорта, придется делать тоже самое (мержить или ребейзить свои правки) на актуальные данные.
Если конфликтов при такой ситуации не может возникнуть, то почему бы разработчикам изначально в ветке импорта не работать или как им удобно, а не так как:
master ----------------------- >
└ feature/import-dev ------- >
├ feature/import-head ---- >
├ feature/import-filter -- >
├ feature/import-table --- >
├ feature/import-pager --- >
└ feature/import-footer -- >Но когда разные части делаются не в синхроне и из мастера автоматом изменения доставляются на стейдж, мы получим таким путем сбой доставки в прод.
Так у вас же спринты, вы в начале спринта делаете ветку спринт№123 и она становится dev веткой, а когда спринт заканчивается вся ветка вливается в мастер и релиз (ну так по обычному git flow).
Если вы делаете отдельные фитч ветки вроде import и тд и потом по мере готовности вливаете в master и делаете сразу релиз, то у вас получается github flow и зачем вам использовать спринты? делайте релизы по мере готовности без привязки к спринту.
Я просто участвовал в подобной реализации такой фичи и в начале тоже планировали одно, а надо было совсем другое, чем раньше показывается промежуточный результат, тем быстрее понятно в ту ли сторону вы двигаетесь точно также и про процесс разработки, чем он проще и легче, тем больше времени на разработку, это лишь мое имхо возможно я ошибаюсь.
разработчикам работающим над импортом придется учитывать и влитые эти задачи и при merge или rebase могут возникнуть конфликты, далее разработчики что не влили в ветку импорта, придется делать тоже самое (мержить или ребейзить свои правки) на актуальные данные.
Ветка import-dev в мастер будет сердиться только когда есть уверенность в ее стабильности (проверена qa и дана резолюция, что критических багов нет). К этому моменту все атомарные ветки девелоперов уже должны быть влиты в dev. Как я писал ранее. Дальше будет ребейз или мерж двойной. Почти наверняка будет конфликт в yarn.lock + быть может в package.json. других конфликтов с чужими мержами в мастер не должно возникнуть, если не правили общие компоненты.
вы увидели что ветка import отстает от master
в master есть что то очень важное
ветка import прошла qa и что касается фичи все ок, но есть конфликты с мастером и надо убедится что не будет регресов после внивания в мастер, так получилось что общие компоненты правили.
теперь когда изменения из master будут вливаться возник конфликт, как определить кому их разрешать? у вас в ветке знания размазаны по различным ролям (куча людей) и та ветка что влита была тоже знания размазаны по куче людей, как убедится что разрешение конфлитка ничего не сломало?
Так у вас же спринты, вы в начале спринта делаете ветку спринт№123 и она становится dev веткой, а когда спринт заканчивается вся ветка вливается в мастер и релиз (ну так по обычному git flow).
Гит флоу и расписание спринта разных команд — это совсем разные темы. Кроме того гит флоу — это рекомендация и всегда подлежит адаптации под конкретную команду. Не всем заходит гит флоу в полной реализации.
так вы пытаетесь выдавить скорость из разработки, паралеля все что можно, но при этом все равно привязаны к сроку спринта в 7 или 14 или сколько там у вас он идет и фидбэк будет собран не раньше его окончания, а если фидбэк будет собран раньше то зачем спринты? и релизы вне спринта.
я вижу разбиение задач и их планирование у вас как в waterfall, но при этом аргументируете это гибкой разработкой и скоростью, хотя я опять же могу ошибаться, главное чтобы вам нравилось.
я бы предположил что вам может подойти канбан, по крайне мере по тому как вы работаете с гитом, как раз тут спринты не нужны, как освободились люди берут новую таску, по мере готовности собирается фидбэк, релиз по таскам отдельно (не привязано ко всему спринту) и в произвольное время.
так вы пытаетесь выдавить скорость из разработки, паралеля все что можно, но при этом все равно привязаны к сроку спринта в 7 или 14 или сколько там у вас он идет и фидбэк будет собран не раньше его окончания, а если фидбэк будет собран раньше то зачем спринты? и релизы вне спринта.
На тестовую среду можно доставлять из ветки dev. Показать прототип PO или ещё какому-нибудь внутреннему пользователю можно значительно раньше, не синхронизируясь с циклами разработки других команд.
я вижу разбиение задач и их планирование у вас как в waterfall, но при этом аргументируете это гибкой разработкой и скоростью
Гибкие методологии разве требуют избавиться от планирования?
Спринт планируется. Базовая спека от PO насыщается деталями аналитика в команде или самими разработчиками. В пределах спринта (по скраму если) всеми силами нужно придерживаться плана на спринт. Без планирования в аджайл получаем канбан, в котором команда просто отрабатывает прилетающие в реалтайме карточки на доске (конвейер).
Гибкие методологии разве требуют избавиться от планирования?
я этого не говорил.
Помните в самом начале написал мысль о том что "9 женщин не смогут родить ребенка за 1 месяц" если переводить мысль более подробно, то вы пытаетесь большое число сотрудников (ролей) задействовать в разработке ОДНОЙ фичи и пытаетесь в рамках этой фитчи ее оптимизировать чтобы стартовать скажем так подзадачи параллельно. При этом большое число ролей работающих над одной фитчей должны между собой комуницировать и шарить знания, что тоже как бы затратно.
Вместо этого проще брать больше фитч в работу и меньшее число сотрудников оставлять в работе над фичей (у вас там по фронту только 6 частей идет паралельно, а значит это разные сотрудники или он будет выполнять эти задачи последовательно).
За счет меньшей команды у них будет меньше комуникаций между ролями и больше времени на работу, пусть они там в 2 или 3 сделают фитчу чуть позже, чем как вы указали в 6 или больше, хотя разница во времени будет небольшой, при этом другие 2 — 3 человека смогут взять и делать другую фитчу для бизнеса паралельно и к концу спринта (плюс например неделя вы получите уже две фичи вместо одной, неделя это цифра с потолка).
Поэтому я думаю надо оптимизировать не выполнения одной задачи большим числом людей(ролей), а паралельно запускать большое число задач (в соответствие с доступными ресурсами и доступными задачами для запуска паралельно).
Я лишь прочитал и высказал что мне кажется может не сработать, при этом я согласен что в начале фронт потом бэк, просто я думаю некоторые вещи иногда нет нужды запускать паралельно, полученный профит по срокам может быть перекрыт от проблем с комуникациями и переделками, тут все надо выбирать индивидуально (от команды).
я вас понимаю… главная цель в контексте статьи — при фиксированном составе команды максимально ускорить разработку конкретной фичи при минимизации рисков больших переделок.
ваше предложение в иной ситуации также уместно. Если, напр., в дополнение к основной фиче взять тех долг или обращения в ТП, то именно ваш вариант и выйдет.
точно также и про процесс разработки, чем он проще и легче, тем больше времени на разработку, это лишь мое имхо возможно я ошибаюсь.
Тут вы правы. Я сам за максимально простую реализацию. В заключении как раз и написал про это. Возможно, церемонии с бранчами и не нужны вовсе, если девелоперов договорились о работе в отдельных папках или файлах.
E2e тесты покажут, что код им соответствует, а не что код соответствует ожиданиям. Без человекочитаемой спецификации, заапрувленной ПО или стейкхолдером, откуда брать ожидания? Как контролировать отсутствие ошибок в тестах? Откуда вообще могут появиться баги?
E2E отражают ожидания(требования).
если меняются ожидания то правят и E2E, после правки E2E проект может перестать им соответствовать.
Вместо спеке конкретный набор критериев(тестов) которым должна соответствовать система, если система не соответствует ожиданиям значит мало критериев и надо уточнять.
Как контролировать отсутствие ошибок в тестах?
Если система соответствует тестам, но не подходит тем кто заказывал ее то значит ошибки где то в тестах, меняются тесты и следом система.
Откуда вообще могут появиться баги?
Философский вопрос, хоть откуда если коротко.
Поэтому лично я категорически согласен с содержимым статьи. + в статью и карму.
Как оказалось дизайн в контексте web-интерфейсов — это не столько про «иллюстративно-художественную» часть, сколько про решение проблем бизнеса с помощью интерфейсов (один из переводов слова дизайн — проектирование).
Могу сказать с позиции фронтенд разработчика, что это одни из самых ценных приобретённых знаний. Уровень «страданий и стресса» при взаимодействии с постановщиками задач и с бекендом сократился на порядки.
Основы дизайна (ещё раз, не художественного, а именно как проектирование), развивают чуйку и умение задавать правильные точные вопросы. С достаточно большим процентом точности можно предсказать куда будет расти «простоя задача». Т.е. что в задаче есть «вода» и неопределённые требования (поэтому на продумывание можно забить и сделать «в лоб»). А что есть ограничения на всё время жизни проекта (как правило скрытые, которые нужно «найти» между строк среди потока мыслей постановщика задачи), соответственно, нужно продумывать более надёжную фронт-архитектуру.
Очень мило иногда получалось, когда фулл-стек-синьоры делали какой-то параллельный проект. А после сдачи ко мне подходит начальник IT и говорит сделай по нормальному..) и можешь сам ставить задачи этим разрабам. И ещё куча подобных кейсов.
Также заметил минусы обладания основами дизайна:
— 80% дизайнеров теперь кажутся просто «операторами фотошопа»;
— 99% digital-маркетологов теперь кажутся кхм… «плохими людьми»;
— меньше пишешь кода, больше разговариваешь, часто зовут на митинги с топ-ами при обсуждении их новых чудо-идей;
— могут переманить в «менеджеры»;
— дольше делаешь вёрстку (и в целом фронт) чем раньше;
А есть советы относительно того, как всё таки наработать хотя бы начальные навыки создания интерфейсов. Именно в механическом смысле. Я вот в голове могу представить, но когда начинаю делать, сразу тупняк жесткий наступает))
Что касается советов для появления «автоматических/механических» навыков, то сходу вспоминается следующие:
- Каждый раз проектируя конкретный экран/интерфейс, необходимо задавать себе вопрос — “Что сейчас важно для пользователя?”, “Что я хочу показать пользователю в данный момент?”, чтобы понимать как спроектировать и распределить внимание в конкретном случае.
- При проработке пользовательского сценария — научиться/натренироваться мыслить экранами для достижения цели пользователем. Я обычно на большом листе бумаги делаю наброски всех экранов всех возможных состояний конкретного сценария. Это кстати помогает более точно и быстро сформировать иерархию компонентов и их названия (в случае react-а допустим)
- Не заставлять думать или много читать пользователя. Он должен сфокусироваться на том что хочет (цель), а не на том что он делает (автоматизм, интерфейс должен “исчезнуть” Идеальный интерфейс — это не кнопка «сделать всё хорошо», идеальный интерфейс — это его отсутствие, когда уже всё хорошо.)).
- Не вводить в заблуждение пользователя — каждая ссылка или кнопка должна чётко отвечать на вопрос что произойдёт дальше, без всяких двусмысленностей. Не «Ок/Отмена», а «Да, сохранить / не сохранять». Но это больше тема интерфейсных текстов — отдельный пласт знаний. Гуглить Максим Ильяхов.
- Фокус внимания пользователя ограничен (например, 10% внимания на ваш интерфейс, 90% на управление авто). Поэтому чем меньше плотность информации на еденицу площади — тем лучше.
- Каждый блок может содержать не более 5-7-9 элементов (правило 7 ± 2). Если элементов больше — нужно их разгруппировать.
- На одном экране — один акцент (читай, одна главная cta-кнопка, например.). Если акцентов больше — то само понятие акцента исчезает.
- Правило внутреннего и внешнего. Это, например, есть несколько списков на одном экране. Так вот, расстояние между ul должно быть больше расстояния между li.
- Если уже есть какой-то интерфейс и нужно его как-то улучшить — то в первую очередь лучше думать что убрать, а не чего бы ещё добавить.
- Ссылка — это объект (существительное), а кнопка — это действие (глагол, «отправить», «выйти», «заказать» т.д.)
Понятное дело, это не догмы.
А зачем изучать дизайн, чтоб понимать как будет выглядеть. Сделайте на каком-нибудь UI фреймворке, чтобі совсем страшно не выглядело и определитесь с тем, что должно быть на странице/экране/форме, чтобы было удобно пользоваться функционально. А красиво уже потом как-нибудь, если будут ресурсы.
Почему, для создания прототипа одной страницы нужно 5 фронтендеров?
Ну можно было подобрать пример и посолиднее. Просто увеличилось бы количество воды.
Чтобы сделать прототип в, например, 3 раза быстрее чем может сделать один
Если еще и GraphQL — то куча всего переиспользуется, и особо думать даже не надо как API строить. Плюс есть еще BaaS-сервисы — через UI накидал схему данных, оно тебе API, и вообще бекендеров не надо.
Если что надо делать непонятно — то и фронт, и бек пока рано писать. Потому что фигня получится под переделку. В этом случае надо прототипировать на картинках, уточнять требования, придумывать схему данных.
Ситуации когда фронту нечем заняться пока бек что-то там делает, могут вызваны следующими причинами:
1. бек натащил паттернов, навернул лишнего, и теперь банальное «сделать API для таблички» — это уже для них сложно. Типичная сейчас история, кстати.
2. архитекторы, аналитики и UXD — перегружены разгребанием текучки, и не планируют наперёд
3. вообще нет планирования заранее и наперёд, едем в стиле злого аджайла — «ща чего-нибудь нафигачим, а дальше всё пять раз перепишем».
Короче лечить надо причину, а не следствие.
Через файловый API браузера просим пользователя выбрать нужный файл с диска.
Если для экспорта из 1с то это уже хреновая реализация
Через AJAX отправляем файл в бэкенд.
Стопиццот дофигаллиардов позиций одним файлом за одну загруку это прям не очень удачная идея. CSV вполне можно резать на части, грузить и обрабатывать поэтапно.
Ожидаем окончания валидации и распарсивания файла с данными (опрашиваем статус фоновой операции через Websocket).
Long Polling через сокеты? А зачем? Прочитал переписку выше и все еще не понял.
По окончании валидации грузим подготовленные к импорту данные и рендерим их в таблице на странице импорта.
Стопиццот дофигаллиардов позиций, ага))
Пользователь редактирует данные, исправляет ошибки. По нажатию на кнопку внизу страницы отправляем исправленные данные в бэкенд.
И делаем выгрузку из 1с полностью неконсистентной.
Кроме того, в некоторых случаях, например если клиент загружает новые цены, может еще быть желание блокировать работу с товаром до окончания операции. Так что философия «работайте дальше а мы пока загрузим» вполне может быть в корне ошибочна.
Вы еще пропустили пункт разрешения коллизий.
А может быть импорт должен быть одной транзакцией?
В каком виде вы собираетесь показывать результаты и что с ними потом можно сделать?
Стопиццот дофигаллиардов позиций, ага))
Пейджер естественно.
А чо ждать тогда? Первые 30 строк в файлике распарсил и отправил ответ на фронт.
Про csv это к примеру было. Для простоты. Может быть и другой формат (xlsx напр.)
Ну + полчаса, из-за того что библиотека парсящая xls сделана по мудацки
я про то, что частями слать не получится… или есть либа для парсинга XLSX в JS?
https://github.com/SheetJS/js-xlsx например
Еще раз, мы говорим про минимальную херь для презентации. Слать реактивно кусками многопоточно в очередь в извращенных форматах можно доделывать потом до посинения. Ия не вижу разницы долбить csv файл или xlsx на куски. Единственное csv каждый кусок можно читать отдельно наверно. И я думаю что ли бы для js есть какие угодно либы)) это самый популярный язык проганья.
Конечно, имел опыт.
К пейджеру обязательно поисковик и фильтр по некоторым полям. Это стандартные вещи UX.
"Критикуешь — предлагай альтернативу"
В данном контексте скорее всего просто не нужно выводить все данные, только те, что с ошибками. И пейджер либо ещё какая-то навигация кроме простого скролла не нужна. Или ограничить количество показываемых ошибок каким-то разумным значением типа 100 (можно на усмотрение юзера, количество ошибок показывать всегда, можно с группировкой по типам), а вторую порцию выводить только после исправления всех в первой части.
Ээээ… Задача стоит делать две кнопки "импорт csv" И "подтвердить импорт" и табличку на фронте, которая рендерит csv с возможностью редактировать строки? Помню такую херь до обеда делал на прод. Если задача сделать минимально работающий прототип, то реально можно в одну будку сделать за день и бек и фронт. Потом уж прикручивать вебсокеты, css, ActiveMq. Вебсокеты вы как то не так юзаете, кстати… Про дизайн не понял, если проект не с нуля, то компоненты(кнопка, таблица) уже должны существовать с дизайном, нет?..
Закончилась посадка на суперлайнер ИЛ-2086. В салон выходит стюардесса:
Дамы и господа, для того, чтобы помочь вам скоротать время полета,
на борту нашего лайнера имеются библиотека, кинозал, три бара,
ресторан, бассейн и два теннисных корта. А теперь я попрошу вас
пристегнуть ремни безопасности, потому что сейчас вместе со всей этой
финей мы попытаемся взлететь!
Как ей пользоваться можно прочитать здесь.
Сначала фронт, а потом бэк (когда-нибудь)