Разработчики SQLite развивают проект по реализации возможности компиляции библиотеки в промежуточный код WebAssembly, способный запускаться в web-браузере и пригодный для организации работы с БД из web-приложений на языке JavaScript. Код для поддержки WebAssembly добавлен в основной репозиторий проекта. В отличие от API WebSQL, в основе которого лежит SQLite, WASM SQLite полностью изолирован от браузера и не влияет на его безопасность (Google решил отказаться от поддержки WebSQL в Chrome после нескольких уязвимостей в SQLite, которые можно было эксплуатировать через WebSQL для атаки на браузер)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58004
не понятно, зачем оно нужно...
Главное, что модно. Остальное не важно. И при этом будут всех уверять, что это так необходимо. Эту кипучую деятельность необходимо направить на пользу.
Веб приложения PWA, невозможно заблокировать (удалить из магазинов Приложений), кросс платформенны по умолчанию, sql подобные данные можно сразу импортировать на сервер для хранения, удобно строить иерархичные структуры и вполне возможно даже работать будет при использовании join быстрее чем noSQL, легко поддерживать и находить разработчиков т.к. многие знают js
Много маркетинговых слов, но нет ответа на простой вопрос: зачем?!
Очень даже полезный инструмент для переваривания условно-больших данных.
Массивы в JS имеют дикий перерасход по размеру используемой RAM. А теперь большие базы можно ворочать прямо в браузере...Ясен пень - этот движ педалируется для Chrome_OS, а в Chrome_Browser обкатывается бета-версия технологии.
> больших данныхЗачем?! Зачем у клиента ворочать бигдату?
А что, на своих серверах машинное время тратить? Юзер все равно ничего полезного не делает...
> Юзер все равно ничего полезного не делаетМайнеры и ботофермеры идут на.
Предположим есть типичная бигдата в районе 100к строк (статистика продаж, например) и клиент хочет сам что-то с ней делать (проводить вычисления для экономических расчетов). Обычно он делает это в эксельке, которая еле запускается и есть рамы в районе нескольких гб.
> 100к строк ... Обычно он делает это в эксельке, которая еле запускается и есть рамы в районе нескольких гб.А ты предлагаешь вместо нативного приложения хттп-хтмл-ссл-вебасм-жыэс-аякс-скуля-локалсторыж-сёрвисворкер-хром, которые выжирают в 10 раз больше гигабайт и работают в лучшем случае через раз...
100к строк -- это не биг дата.
Ну и всё-таки, делать подобное в браузере хоть и можно, но это на порядок менее эффективно, чем на стороне сервера. Одна передача данных чего будет стоить.
>> делать подобное в браузере хоть и можно, но это на порядок менее эффективно, чем на стороне сервераНу, как бэ, на стороне сервере может быть в миллиард раз эффективнее, но "за свои", а в браузере - расходы клиент оплачивает. Т.е. до тех пор, пока это можно сделать "приемлемо отзывчиво" прямо в браузере у клиента, там и делать будут, вне зависимости от серверной эффективности.
> а в браузере - расходы клиент оплачивает. Т.е.
> до тех пор, пока это можно сделать "приемлемо отзывчиво" прямо в
> браузере у клиента, там и делать будут, вне зависимости от серверной
> эффективности.100к строк -- отзывчиво. Ещё раз -- ЭТО НЕ БИГ ДАТА.
Когда начинается биг дата -- передать на сторону клиента -- пока дождёшься окончания передачи на сторону клиента -- успеет пару раз наступить тепловая смерть вселенной.
Мне кажется что PWA приложения это не про перенос вычислений на сторону клиента, не про полную отвязку веб-приложения от сервера. PWA приложения это про способность запуститься и выполнять "часть" операций без интернета в случае если у переносного устройства он пропал. Например у телефона и планшета интернет непостоянный. Даже у ноутбука если его куда-то носят интернет будет не всегда.
Ну смотри - как нынче поступает веб-макака, которое по БД не знает от слова "совсем".
Данные через ORM он тянет двумя способобами - сразу все зараз (насколько ему позволяет буфер) и 1000 раз по одной.А тут будет механизм - вытянуть нужное кол-во записей и крутить его локально.
"вытянуть нужное кол-во" - это которое из: все зараз или 1000 по одной?
> Массивы в JS имеют дикий перерасход по размеру используемой RAMНу чо, всё правильно, вполне по-жабаскриптному.
В js есть типизированные массивы которые хранят не ссылки на объекты, а значения
Как будто Гугл не может просто добавиь SQLite в ХромОсь, а потом приделать очередной кастомный API для доступа к нему из браузера на ХромОси.
Гуглу что угодно может в голову прийти, сначала удалили websql, а потом опять вставят.
В этом мире всё бывает только либо ради секса, либо ради денег - выбирай.
Перельман с тобой не согласен
Какие-то 0.00...01% фриков не в счёт. Тем более Перельман не бедный человек уже, если ты читал его работы, то знаешь, что он одну из ключевых подписал "спонсирование этой публикации было сделано на личные сбережения". И он сам признавалася, что после работы в США денег ему хватит до конца жизни. Поэтому либо секс, либо деньги.
Чтобы было больше смузи
Опеннет эксперты зрят до самого глубокого дна (той ямы в которой находятся) и готовы видеть маркетинг даже в собственном отражении
Зачем нужны какие-то маркетинговые веб так называемые приложения, когда сильно нанять нормального программиста на си и он сделает все как надо
1. Одного программиста на Си будет недостаточно.2. Они хотят много деняк, т.к. программируют на системном языке. Тут я возможно ошибаюсь. Но если им платят меньше, чем жабоскриптерам, то у них меньше мотивации будет оставаться сишником. Ведь на условном жабоскрипте кодить легче, особенно после сишечки.
3. Их мало. Всё меньше и меньше. А жабоскриптеров тьма.
Им платят сильно-сильно меньше чем JavaScript-ерам, прям совсем дно. Им вообще платят практически меньше любых программистов на других языках.Работы вот прям совсем нет, очень мало, единичные вакансии. Приличных нет совсем.
После Samsung мне предлагали кодить этот суперсамолет Су-55 (ПАК ФА) за какие-то жалкие 50к, ну максимум 60к. Когда ребята с Java уходили на 200-300 в банки.
Это только в бурных фантазиях "экспертов" opennet они элита сишки и считают что они то уж не быдлокодеры, в отличие от "веб-макак".
Ну и выучить Сишку проще простого, это самый лёгкий язык, гораздо проще JavaScript.
Вот такая реальная печаль на самом деле. И это в Москве лет 7 назад. Сейчас всё ещё хуже для Сишников.
>После Samsung мне предлагали кодить этот суперсамолет Су-55 (ПАК ФА) за какие-то жалкие 50к, ну максимум 60к. Когда ребята с Java уходили на 200-300 в банки.Знакомая программы для спутников писала для микроконтролеров миландр тоже за примерно такие суммы. Грустно.
Это при том что у нас один из самых больших военных бюджетов в мире.
Просто бюджет уходит на генеральские дачи, что в свете последних событий оказалось не так уж плохо - быстрее закончится.С другой стороны, бюджет уходит на клининг-услуги через одну мутную конторку по штампованию образов с патриотичненькими обоями.
> 50к, ну максимум 60к ... И это в Москве лет 7 назадХарош заливать, у нас сварщики получали от 60к, и это не в Москве лет 10 назад. С твоими "способностями" для тебя и 25к - много будет.
Ты объявления то посмотри и сколько предлагают Сишникам)))Что, обидно стало, что ни х...не платят? На меня решил свою желчь излить?)))
И это такие ЗП во многих конторах, средняя 50-70, до 100к.
САМОЕ БОЛЬШОЕ 150к в мэйле))) Те в 2-3 раза меньше нормальных программистов)))
Которые не только Кернигана-Ричи прочитали)))
Веб PWA приложения это очень хорошо, но для них есть встроенная в браузер indexeddb
Без необходимости выкачивать большую библиотеку
Замечательно, а запросы как вы к ней будете строить?
На линзах. Другое дело в том, что оно жрёт.
1) Откройте для себя мир правильно структурированных ключей. Что-то вроде такого:
/users/admins/vasya
2) Не нужно тратить время на походы по сети. Это в десятки тысяч раз ускоряет выборку данных.
3) Если не использовать внешние ключи -- агрегатное хранение на порядок быстрее.
4) Если использовать внешние ключи -- вы ничего не теряете. Скорость будет немного выше, так как не тратится время на парсинг, компиляцию и оптимизацию запроса (эту часть придётся сделать руками, но можно в 2..3 раза оптимизировать, по сравнению с РСУБД).
5) К слову, материализованные графы, поток линейного логирования, сырых измерительных данных -- всё это дурно влияет на производительность РСУБД. Более того, они от таких режимов дохнут.
6) Слабо структурированные данные, жирные двоичные блобы -- РСУБД вообще для этого не предназначены. Да и с шардированием (в меньшей степени репликацией, но тем не менее) -- тоже всё достаточно грустно. Это мы ещё до биг даты толком не доехали, угу.
Закат Солнца вручную далеко не всегда оправдан. Но если в организации 50..100 БД или больше -- затраты организации на железо будут сокращены кратно. Начальство такое любит.
Понятно, реляционную алгебру не осилил.
пытайся дальше... когда-то - осилишь.
> Понятно, реляционную алгебру не осилил.Понятно. Вообще не читал мой ответ.
После "мир правильно структурированных ключей" дальше можно не читать.Человек вообще не понимает о чём пишет.
Если не понимаешь разницы между ключ-значением и реляционной БД, то посчитай хотя бы алгоритмическую сложность, эксперт)
Но IndexedDB поддерживает, разные Store, они же таблицы в sql и коллекции в mongodb. Даже редис так не умеет, там фиксированно 16 таблиц на все ключи.
Поддерживает запросы по ключу и диапазону ключей.
Поддерживает транзакции.
Прямо как маленькая mongodb встроенная прямо в браузеры. С одним API на все браузеры.
В этом суть моднявых языков типа джавы и руста
Джавараст!
растаджа
"Данные, которые web-приложения сохраняют в WASM-версии SQLite, могут быть локализованы в рамках текущего сеанса (теряются после перезагрузки страниц) или сохранены на стороне клиента (сохраняются между сеансами)."Слово "Трекинг" просматривается насквозь.
Какие глупые веб-челлвекообразные.
Вместо того чтобы для трекинга сохранить данные в cookie и localStorage они выдумали качать библиотеку скомпилированную в web assembly
Что вообще в голове у этих людей
Ты, похоже, никогда не слышал про обфускацию.
Ты видимо слышал, но что это волшебное слово значит не понимаешь.
Рассказывай какой отношение обфускация имеет портированию SQLite библиотеки на webassembly
Ничего ты не понимаешь. Тут, понимашь, эксперт слово молвит. Понимать надо!
> портированию SQLite библиотеки на webassemblyВ последнее время всё больше вижу вебмакак, забивающих гвозди подушками.
В последнее время всё больше вижу опеннет экспертов, по которым не понятно это скрипт или человек такой странный
> Какие глупые веб-челлвекообразные.
> Вместо того чтобы для трекинга сохранить данные в cookie и localStorage они
> выдумали качать библиотеку скомпилированную в web assembly
> Что вообще в голове у этих людейШтука в том, что современные браузеры предоставляют слишком удобные интерфейсы для юзера чтобы покапаться в этих самых печеньках и сторейджах. Можно даже подправить значения или удалить все напрочь.
Толи дело самопальный webassembly код который пишет непонятно что непонятно куда.
Это вы зря, очень удобно. Не надо городить свое, когда вам надо поискать к примеру по 2 ключам.
Аноним одобряет, особо радует что это не LibreSQL (или как его там, из соседней новости), а нативный скулайт.
Мы вам встроили ОС в браузер, чтобы вы пользовались ОС, пока пользуетесь ОС, пока сидите в браузере.
Моднявые сму..технологии и до sqlite до́брались. Скоро его перепишут на электрон и он не быдет работать без npm
Я тебе больше скажу они стали использовать WASM без браузера! Как просто обычный бекенд. Говорят очень безопасно.
В wasm сразу встроены все необходимые алгоритмы безопастности, которые только нужны, что не сказать о нативных кодах. Это пища для размышления.
Да наслушался такого. И того что на WASM нет нормальной документации и всего такого им приходится самим разбираться. Пишут кстати на расте. Такая безопасная безопасность что её приходится оборачивать в другую безопасность, чтобы было безопаснее.
Так единственный кросплатформенный выхлоп у раста - это именно васм. Как и у сишки и у прочего, что поддерживает ллвм. В общем-то, у них особо и выбора нет в чём ковыряться )Хотя мантр про безопасную безопасность по определению ведь не натив наслушался ещё во времена роста популярности джавы в 90/00-е. Тогда ведь многие полагали что за ней будущее даже эпичнее чем сейчас у жс, раста, васма и питона вместе взятых.
Но не взлетело. Оказалось что в абстрактном воображаемом сыре дырок не меньше. И чем он абстрактней - тем их больше
>Как и у сишки и у прочегоТы, похоже, никогда не слышал про posix
Ох уж эти современные так называемые программисты.
> Ты, похоже, никогда не слышал про posix
> Ох уж эти современные так называемые программисты.Месье откровенно перепутал два понятия: идея и реализация.
Автомобиль -- идея.
Лада -- реализация идеи автомобиль.
Если идея хороша, не факт, что реализация идеи также будет хороша.
Жаба не взлетела из-за того, что никому просто нахрен не нужны были "кроссплатформенные" приложения. Народ пожимал плечами на "то же самое, только в браузере" и продолжал пользоваться нэйтивом.
Сейчас ситуация ничуть не лучше: все <b>платёжеспособные</b> клиенты сидят по-прежнему в Венде, Линукс радостно глотает пыль, несясь по обочине, огрызкофилы вообще не знают в своей цифровой диктатуре "что такое не эппл", а мобильные приложения вообще не нуждаются в громоздком десктоп-дизайне.
Так что макаки попрыгают со своими "десктоп-в-браузере", да опять забросят.
Хуясе у него жаба не взлетела
Настолько не взлетела, что 25 лет уже не взлетает
Позор что так называее программисты не знающие что такое шина адреса и чем отличается Гарвардская архитектура добрались до sqlite
> и чем отличается Гарвардская архитектураМолодец, спародировал сам себя. И Фон Нейман тут не при чём.
Последний год без SQL на фронтэнде.
https://sql.js.org уже давно был + есть реляционные бд поверх indexeddb, например, https://github.com/google/lovefield. Но хз где это в реальности применяется.
Самое забавное что SQL уже пыталичь просунуть в Web в виде WebSQL, но прокатило, даже Чрому пришлось отправить его на снос, и тут же появляется SQl через WebAssembly. Да еще и опять с сохранением данных на клиенте. Как своевременно.
Ты не понимаешь WebSQL небезопасно. Тоже самое в WASM должно быть безопасно, как минимум в теории.
А на практике будут пересылать файлы бызы данных, сгенерированные на фронтэнде, на бэкенд, и открывать там. В результате - RCE.
Придётся WASM на грусти переписывать.
Когда хотел схохмить... Открой для себя Wasmer - среду выполнения модулей WebAssembly, написанную на расте.
> Когда хотел схохмить... Открой для себя Wasmer - среду выполнения модулей WebAssembly,
> написанную на расте.Среду не хочу, пятницу давай.
> пятницу давайЗабавно :) Ты в курсе, какого гендера был Пятница?
Гендеры, шмендеры, какая в задницу разница.
WebSQL всё-таки был частью браузера, а тут - просто вебмодуль т.е часть клиентского кода вебстраницы. Даже если его и ломанут, то смогут делать лишь то что может делать жс на вебстранице.А в первом случае - можно было бы и под капот браузера пролёту через взломанный его компонент
> если его и ломанут ... лишь то что может делать жс на вебстраницеAPI File System Access... Если его ломанут...
Если его ломанут, то никакой sqlite уже совершенно не нужен.
JS обертку над простыми файловыми операциями взломают?
Если это случится то будет доступен весь каталог пользователя на запись и все его данные + возможность сделать автозагрузку всего чего угодно, а так же ненужные уже системные файлы на чтение.
у веб-макак что угодно ломанут. Видишь джаву, считай что там уже дырень.
Так ломают то у тру олдовых элитных С++шников.
> у веб-макак что угодно ломанут. Видишь джаву, считай что там уже дырень.Казалось бы причём тут джава?
Websql знаменили на indexeddb
Порт SQLite для WebAssembly понадобится не для того чтобы местные клоуны вываливали свои фантазии о том как происходит разработка в комментарии, а для сложных PWA приложений.
Браузер это кросс-платформенная среда выполнения, предоставляющая ABI не зависящий от операционной системы, архитектуры процессора, порядка байт и к тому же обеспечивающая хорошую изоляцию от остальной ОС.
Такие приложения не нужно устанавливать на тысячи компьютеров, они будут загружать свои компоненты по мере их обновления, автоматически.Можно написать Offline-first PWA приложение, а способное работать без интернета, и ему как раз может понадобится база данных сложнее IndexedDB.
Подключил WebAssembly SQLite библиотеку, она тебе предоставила Promise API и пишешь запросы. Результаты сохраняться на диск через File System Access и будут синхронизироваться с бэкэндом, при появлении интернета.
Для мобильных приложений offline-first очень часто делают https://developer.android.com/topic/architecture/data-layer/...А теперь и для PWA
> Браузер это кросс-...Расскажи эту сказку микрософту, например. Который в свои новые браузеры встраивает дотнетапплеты. А самое печальное - сайты используют это... В итоге - сайт не работает, кроме последних венд с эджо-ослом.
Как будто необразованные веб-макаки не знающие что такое шина адреса и пихающие в каждый hello world на джаве по 100500 npm зависимостей, могут это понять.
>джаве по 100500 npmнет я конечно согласен что жс произошёл от жавы (и потом немножко наоборот), но это всё же некорректно называть одно другим, там достаточно мало общего осталось.
>сложных PWA приложенКогда слышу такое хочется кричать - А ПОЧЕМУ НЕ СДЕЛАТЬ НОРМАЛЬНЫЙ КЛИЕНТ-СЕРВЕР? На нормальном ЯП, с нормальными библиотеками сети/бд, с нормальным протоколом РПЦ, который поддерживает только домен нашего преложения, и наконец с нормальным родным гуем для каждой платформы? Почему нормальная разработка уже не в моде? В операционку тащат браузерного монстра, чтобы он сдеал то что она уже умеет, но с дикими затратами памяти/проца и задними дверьми в самых неожиданных местах. Мир точно где-то срвернул не туда.
Иногда нормальный клиент-сервер делают. На dot.net получается родной гуй для каждой версии винды и все давольны.
У нас на работе фронтэнд для пользователей на react/javascript и android/kotlin
А фронтэнд биллинга на react. Биллинг запускают и из gnu/linux, из windows и из mac os x и даже из планшетов android так как большая часть сотрудников удаленщики.Вот я думаю, оставшимся 2м программистам нужно переписать это на НОРМАЛЬНЫЙ КЛИЕНТ-СЕРВЕР без смузи-технологий, чтобы опеннет эксперты были довольны. Там и так 5 языков программирования и 8 фреймворков, поэтому если добавить к ним еще 3 (языка и фреймворка) с них не убудет.
для клиентского frontend был бы очень полезен offine-first, но его нет. Собственно у нас по уму и должно было бы быть настоящее PWA приложение для клиентов, но...
Те чтобы приложение на каждый чих лезло с запросом на сервер и тратило 200-300 мм (а то и больше) только на задержки сети?Да вы, батенька, гений.
>>сложных PWA приложен
> Когда слышу такое хочется кричать - А ПОЧЕМУ НЕ СДЕЛАТЬ НОРМАЛЬНЫЙ КЛИЕНТ-СЕРВЕР?
> На нормальном ЯП, с нормальными библиотеками сети/бд, с нормальным протоколом РПЦ,
> который поддерживает только домен нашего преложения, и наконец с нормальным родным
> гуем для каждой платформы? Почему нормальная разработка уже не в моде?
> В операционку тащат браузерного монстра, чтобы он сдеал то что она
> уже умеет, но с дикими затратами памяти/проца и задними дверьми в
> самых неожиданных местах. Мир точно где-то срвернул не туда.Ну ты приведи пример таких технологий. Все свернули на электрон, потому что это тупо дешевле в том числе и в плане поиска людей.
Так местные клоуны дальше вызова malloc и не продвинулись.Всё ещё думают что JavaScript для анимации статичных страничек, как в старые добрые времена.
Собственно, в этих временах и своих фантазиях они и застряли.
JS хорош, а все разрабы на нем - г...о.
>[оверквотинг удален]
> Браузер это кросс-платформенная среда выполнения, предоставляющая ABI не зависящий от
> операционной системы, архитектуры процессора, порядка байт и к тому же обеспечивающая
> хорошую изоляцию от остальной ОС.
> Такие приложения не нужно устанавливать на тысячи компьютеров, они будут загружать свои
> компоненты по мере их обновления, автоматически.
> Можно написать Offline-first PWA приложение, а способное работать без интернета, и ему
> как раз может понадобится база данных сложнее IndexedDB.
> Подключил WebAssembly SQLite библиотеку, она тебе предоставила Promise API и пишешь запросы.
> Результаты сохраняться на диск через File System Access и будут синхронизироваться
> с бэкэндом, при появлении интернета.О, очередные влажные фантазии про PWA-который-вот-вот-захватит-мир. Какая это там уже итерация по счету?
Пока что PWA мне напоминают морские приливы и отливы - покричали, поигрались, бросили, через годик другой опять сделали открытие. И каждый раз оказывается что опять не хватило API, не хватило функционала, вот уже решили SQL прикрутить, теперь-то точно вхлетит!
Последнее время от PWA как раз отказываются. Эппл заблокировала некоторые функции PWA из-за проблем с конфиденциальностью. Мозила с FF 85 (всего-то 2021 год) дропнула часть функционала PWA. На мобильниках PWA усиленно выжирают батарейку.
Ну да, все и правильно. Пофиг на производительность и размер этих помоев.
Апи взаимодействия с бд синхронный, хотя в websql был как синхронный, так и асинхронный вариант https://www.w3.org/TR/webdatabase/#sql. Чтобы долгие операции не вешали ui их предлагается выносить в отдельный веб-воркер?
Их предполагается переписывать с ORM на SQL.
https://sqlite.org/wasm/doc/trunk/api-oo1.mdНо там же есть Object Oriented API, зачем с него переписывать?
Как это поможет от блокировки главного потока?
https://sqlite.org/wasm/doc/trunk/api-worker1.md#promiserВот же оно уже вынесенное
воркер на воркере воркером погоняет... И чего это браузеры начали тормозить круче паровоза в вертикальную гору?!
В вашем гениальном комментарии сосредоточена вся суть так называемой веб, так называемой разработки
Веб-макаки не умеющие программировать окончательно испортили интернет.
Всем вменяемым людям давно пора переходить на Gopher
И что ты до сих пор не перешёл?
Правильно! Чтобы быстрее современный веб медным тазом накрылся.
Надо ли нам уже надевать шапочки из фольги и учить язык рептилоидов?
> надевать шапочки из фольги и учить язык рептилоидов?Растаманы уже это сделали.
Мне часто кажется что рептилоиды высосали мозг у местных экспертов.
Хммм... Осталась только одна надежда - на РВСН... Иначе эту заразу никак не выжечь... :)
Согласен, без американских стратегических сил с экспертами opennet не справиться.Проблему нужно решать окончательно.