Есть библиотека libp2p для JS/Go/Rust в которой это уже реализовано, и много чего еще. Поднимается нода на сервере (или несколько) и на каждом клиенте. Соединяются с сервером через tcp/websocket/webtransport и получают адреса уже подключившихся клиентов - с каждым можно открыть webrtc соединение. После этого про сервер можно забыть, адреса новых клиентов будут распространяться через webrtc. Можно строить сеть только для открытого документа, а можно сразу для всех клиентов приложения, а поверх нее еще одну сеть для документа. А сервер можно и в качестве TURN использовать, только там это называется Relay. Самостоятельно это писать можно очень долго.
А 1 человеко-месяц react+nodejs разработчика стоит столько же как htmx+python/lavarel? Первых сейчас пруд-пруди любых уровней, а где вы берете вторых в нужном количестве, взращиваете сами, а потом удерживаете зарплатой в +20% к рынку?
Интересный очень проект, скажите, у Вас рендеринг в канвас идет в отдельных воркерах или в основных потоках окон? Используется ли BroadcastChannel для общения между окнами?
Звучит довольно похоже на SRP-6, там тоже на сервер не отправляется пароль, а только всякие криптографические хэши, из которых пароль нельзя получить. Для клиента есть рабочая реализация, для Go наверное тоже
А расскажите про openkey подробнее, это что-то похожее на SRP-6? Мне он нравится, но слишком уж повально все передают пароль в https, и не парятся. Так что я тоже забил. А если между терминирующим nginx и бекендом окажется дырявый логгер - то это проблема devops)
По бекенду: не только от количества пользователей сложность, может быть B2B проект под 100 пользователей но с большими нагрузками, сложной доменной моделью, многопоточными алгоритмами, ML, permissions, распределенными транзакциями, кафкой и всем остальным фаршем. Про аутентификацию не надо забывать, она обычно идет из коробки но есть нюансы. CORS это проблема бекенда, он запрещен по умолчанию в целях безопасности, поэтому клиент ругается. Не знаю, как там в Go, но в .Net все конечно идет из коробки, однако допиливать всегда что-то нужно. Конечно зависит от проекта, CRUD не проблема - но и на реакте todo-app за пару часов запилить можно, только кто за такие проекты платить будет? Во фронте проблема с зависимостями решается фикс версиями в package.json, я перешел на это пару лет назад и всем советую. Обновления большинства библиотек смело можно игнорировать. В переменной все что угодно - смотрите в сторону zod/yup. Валидируем данные с бекенда и от пользователя и больше не боимся атомной бомбы. С другими проблемами тоже есть решения: какой-нибудь jotai/mobx для управления состоянием. Да, технологий дофига нужно, сейчас к сайтам высокие требования в B2C. Вот в B2B полегче, там иногда можно ограничиться chrome/safari, 1440+, без поддержки мобилок, стандартный css из UI-framework.
Как будто на бекенде нет проблем, когда зоопарк сервисов на .Net Framework, .Net Core, python 2/3, Go, зависимости на фортране, деплой только в устаревший облачный оркестратор обвешанный костылями для поддержки всего этого. Ах да, особенности разных SQL БД и боттлнек в шине данных, как же без этого) Есть сложные фронтенды, есть сложные бекенды. Также как есть простые фронтенды и простые бекенды.
Согласен с этим, когда поддержка xattr есть это удобно. Но если их поддержки нет, или она по-другому работает, то все ломается) Ну вот не получается в linux на ntfs права выставить. А с rdf как раз удобно - права на файл прописаны в файле, все есть файл, аминь) И этот файл существовал бы и в linux и в windows одинаково, на любой ФС.
На Solid похоже (https://solidproject.org) Файловая система может быть виртуальной и реализована поверх БД, что дает какую-то отказоустойчивость, или быть "умной" вроде ZFS, тогда даже дедупликация будет.
У меня есть ощущение, что HTML и CSS считаются слишком сложными, поэтому вместо них имеем JSX и множество CSS библиотек. В этой статье как плюс, например, преподносится отсутствие каскадности: не нужно учить приоритеты селекторов. Для тех, кто знает HTML+CSS все эти поделки выглядят как попытка решить проблему, которой нет.
Проблему 1 и 3 может решить хороший ORM, например вышеупомянутый EF. Приведенные в статье примеры действительно выглядят жутко. Проблема 2 не решается даже написанием SQL - часто нельзя предугадать какой план построит БД, да и он может меняться от запуска к запуску. Когда запрос является бутылочным горлышком надежнее использовать SQL, сохраненный на сервере в виде табличной функции или процедуры. Переход на другую БД у меня был, с MS на Postgres, из-за политики. Без ORM было бы очень больно, так что матожидание усилий от 0.1% получается значительным.
Если смотреть на стандарты, то можно взять W3C RDF vCard: https://www.w3.org/2006/vcard/ns-2006.html#Name
Там
familyNameиgivenNameЕсть библиотека libp2p для JS/Go/Rust в которой это уже реализовано, и много чего еще. Поднимается нода на сервере (или несколько) и на каждом клиенте. Соединяются с сервером через tcp/websocket/webtransport и получают адреса уже подключившихся клиентов - с каждым можно открыть webrtc соединение. После этого про сервер можно забыть, адреса новых клиентов будут распространяться через webrtc. Можно строить сеть только для открытого документа, а можно сразу для всех клиентов приложения, а поверх нее еще одну сеть для документа. А сервер можно и в качестве TURN использовать, только там это называется Relay.
Самостоятельно это писать можно очень долго.
А 1 человеко-месяц react+nodejs разработчика стоит столько же как htmx+python/lavarel?
Первых сейчас пруд-пруди любых уровней, а где вы берете вторых в нужном количестве, взращиваете сами, а потом удерживаете зарплатой в +20% к рынку?
По моему опыту SVG выигрывает при небольшом числе фигур, выше 1000 уже сильно тормозит при отрисовке по сравнению с OffscreenCanvas.
Интересный очень проект, скажите, у Вас рендеринг в канвас идет в отдельных воркерах или в основных потоках окон? Используется ли BroadcastChannel для общения между окнами?
Звучит довольно похоже на SRP-6, там тоже на сервер не отправляется пароль, а только всякие криптографические хэши, из которых пароль нельзя получить. Для клиента есть рабочая реализация, для Go наверное тоже
А расскажите про openkey подробнее, это что-то похожее на SRP-6? Мне он нравится, но слишком уж повально все передают пароль в https, и не парятся. Так что я тоже забил. А если между терминирующим nginx и бекендом окажется дырявый логгер - то это проблема devops)
По бекенду: не только от количества пользователей сложность, может быть B2B проект под 100 пользователей но с большими нагрузками, сложной доменной моделью, многопоточными алгоритмами, ML, permissions, распределенными транзакциями, кафкой и всем остальным фаршем. Про аутентификацию не надо забывать, она обычно идет из коробки но есть нюансы. CORS это проблема бекенда, он запрещен по умолчанию в целях безопасности, поэтому клиент ругается. Не знаю, как там в Go, но в .Net все конечно идет из коробки, однако допиливать всегда что-то нужно. Конечно зависит от проекта, CRUD не проблема - но и на реакте todo-app за пару часов запилить можно, только кто за такие проекты платить будет?
Во фронте проблема с зависимостями решается фикс версиями в package.json, я перешел на это пару лет назад и всем советую. Обновления большинства библиотек смело можно игнорировать.
В переменной все что угодно - смотрите в сторону zod/yup. Валидируем данные с бекенда и от пользователя и больше не боимся атомной бомбы. С другими проблемами тоже есть решения: какой-нибудь jotai/mobx для управления состоянием.
Да, технологий дофига нужно, сейчас к сайтам высокие требования в B2C. Вот в B2B полегче, там иногда можно ограничиться chrome/safari, 1440+, без поддержки мобилок, стандартный css из UI-framework.
Как будто на бекенде нет проблем, когда зоопарк сервисов на .Net Framework, .Net Core, python 2/3, Go, зависимости на фортране, деплой только в устаревший облачный оркестратор обвешанный костылями для поддержки всего этого. Ах да, особенности разных SQL БД и боттлнек в шине данных, как же без этого)
Есть сложные фронтенды, есть сложные бекенды. Также как есть простые фронтенды и простые бекенды.
Там в первой формуле -1 в кубе, а во второй в четвертой степени, это зачем так? И что такое альфа, и почему оно в 25 или 98 степени?
Согласен с этим, когда поддержка xattr есть это удобно.
Но если их поддержки нет, или она по-другому работает, то все ломается) Ну вот не получается в linux на ntfs права выставить. А с rdf как раз удобно - права на файл прописаны в файле, все есть файл, аминь) И этот файл существовал бы и в linux и в windows одинаково, на любой ФС.
В принципе никто не мешает развернуть pod локально.
А у оффлайн-онли хранилища есть вполне очевидный минус - нет доступа с других устройств.
А в чем принципиальная разница между xattr и RDF?
На Solid похоже (https://solidproject.org)
Файловая система может быть виртуальной и реализована поверх БД, что дает какую-то отказоустойчивость, или быть "умной" вроде ZFS, тогда даже дедупликация будет.
У меня есть ощущение, что HTML и CSS считаются слишком сложными, поэтому вместо них имеем JSX и множество CSS библиотек. В этой статье как плюс, например, преподносится отсутствие каскадности: не нужно учить приоритеты селекторов.
Для тех, кто знает HTML+CSS все эти поделки выглядят как попытка решить проблему, которой нет.
Кажется, что картинки в разделе "Отступы" перепутаны местами
Проблему 1 и 3 может решить хороший ORM, например вышеупомянутый EF. Приведенные в статье примеры действительно выглядят жутко. Проблема 2 не решается даже написанием SQL - часто нельзя предугадать какой план построит БД, да и он может меняться от запуска к запуску.
Когда запрос является бутылочным горлышком надежнее использовать SQL, сохраненный на сервере в виде табличной функции или процедуры.
Переход на другую БД у меня был, с MS на Postgres, из-за политики. Без ORM было бы очень больно, так что матожидание усилий от 0.1% получается значительным.
Для EF есть расширения, которые тоже умеют в оконные функции. Linq2DB крут, но это все-таки другой синтаксис, который нужно учить.
Ага, понятно. Спасибо