Комментарии 15
Как-то мало ссылок на личный сайт, телеграм-канал, "обо мне", форму обратной связи и ютуб-канал. Может, еще добавить?
Не вопрос. Могу порекомендовать ещё эти каналы:
Core Dump про фундаментальные вещи в компьютерной науке.
PiterJS про ежемесячные митапы жабаскриптизёров.
Твой тайный принц про жизнь и отношения.
Давайте представим, как это всё выглядело бы с традиционным подходом. Берётся реляционная СУБД. В ней создаётся пяток табличек и десяток индексов. Работать с SQL напрямую не удобно, поэтому обмазываются ORM. Работать напрямую с СУБД не безопасно, поэтому прячут её за API сервером. На клиенте работать напрямую c API не удобно, поэтому придумываются какую-нибудь клиентскую обвязку.
Но если мы хотим заговнокодить прототип, мы херакнем json в localstorage и пусть он там лежит... (ну или решим гулять на все деньги и возьмем SQLite)
А если серьезно, бд выглядит интересно, можно чуть подробностей? Как ваши одноранговые пиры друг-друга находят? Как вы защищаетесь от подделки контента вместе с ключами, клиенты же одноранговые?
Зачем говнокодить, если можно писать и быстро, и качественно?
Сейчас для коммуникации используется наиболее надёжный канал - по WebSocket через сервера синхронизации, поддерживаемые энтузиастами. В дальнейшем прикрутим WebRTC, чтобы снизить нагрузку на сервера.
От подделки защищают цифровые подписи, которые формируются для каждого юнита данных, на основе приватного ключа пира, который не покидает его девайс.
т.е. адреса серверов поддерживаемых энтузиастами как-то захардкожены в библиотеке, поставляются в виде конфигурации или что-то подобное? Это точно одноранговость?
Что помешает такому энтузиасту создать полностью альтернативную базу данных, с альтернативным пиром у которого свой ключ, заменить все его сообщения и подсовывать ее избранным клиентам?
Я впринципе догадываюсь что нужно либо доверять энтузиастам, либо поднимать свой севрер синхронизации и поиметь весь головняк сразу от обоих архитектур - единственная точка отказа + пир-ту-пир тормоза.
Сейчас захардкожены. Потом будем хранить их в самой базе, чтобы ретрансляторы сами регистрировались в общем пуле. Любой сервер - такой же равноправный узел сети, как и все остальные. Накреативить он, конечно, у себя локально может всё, что угодно, но другие узлы просто не станут с ним синхронизироваться. Так что доверять тут никому не надо - каждый узел при синхронизации проверяет аутентификацию и авторизацию.
Вы не хотите выпустить этот самый круздб отдельным пакетом, без <s>брайнфака</s> мола внутри, чтобы им люди могли пользоваться, а не только сектанты?
Выглядит интересно, и как минимум какие-то применения для него вероятно найдутся, я бы пощупал но без нагрузки.
А вы не хотите принести мне чашечку чаю? Я бы мог и сам заварить, конечно, но так лень.
Будете в Белграде, заходите, заварю.
Возвращаясь к теме - я искренние восхищаюсь вашей энергией, серьезно, но очень жалко что она расходуется куда-то не туда.
Вот эта штука могла бы, наверное, зайти для всяких криптоанархических игрушек (но не для энтерпрайза конечно), если бы ей можно было пользоваться. Возможно она даже хороша, сложно понять без нормальной документации. Но в таком варианте она останется таким же маргинальным продуктом, как и остальные составляющие $mol.
То есть мы получили настоящую бессерверность, а не то, что маркетологи продают нам как serverless, за которым скрываются на самом деле облачные серверные функции.
Сейчас для коммуникации используется наиболее надёжный канал - по WebSocket через сервера синхронизации, поддерживаемые энтузиастами.
Ну как-то...
через сервера синхронизации, поддерживаемые энтузиастами
То есть я сохранил данные, они записались на сервер энтузиаста, потом перед синхронизацией у него пропал интернет, и ничего не синхронизировалось, потом пока не было интернета он решил "да ну нафиг вашу CRUS DB" и удалил все файлы. Получается, я потерял данные, и они зависят от воли какого-то энтузиаста? Ненадежно.
Другой вопрос. Я сохранил 100 Гб данных. Получается, у всех энтузиастов забьется канал, пока эти данные будут синхронизироваться? Что если у кого-то нет столько свободного места на диске, а библиотека в следующий раз меня подключит к нему, чтобы эти данные прочитать?
Данные прежде всего сохраняются локально, так что потерять их реально сложно, ибо при наличии онлайна они реплицируются минимум на 2 узла. Тут скорее есть противоположная проблема: удалить данные не так-то просто - очистки хранилища не достаточно.
Прежде всего забьётся ваш собственный канал, память и процессор, ибо вам эти данные придётся нарезать, подписать, а потом сформировать и отослать пакеты. А для распределения нагрузки на узлы синхронизации предполагается сделать шардирование.
Можно долго кидать минусы г-ну Карловскому, но его почему-то всегда интересно читать))
indexedDB на стеройдах порадовал, но я лучше пока по старинке. Nestиком да Prismочкой...
Хоп, Хлоп, и MVP готов
Нашёл на просторах Хабра картинку в тему.
Хоп, Хлоп, и MVP готов