Comments 33
Хм, если уже был бэк на GO, то почему бы не посмотреть в сторону Wails?
есть ещё https://github.com/DioxusLabs/dioxus из интересных проектов.
изначально был на webview.
осенью добавили Dioxus Native (on the GPU with WGPU).
дистриб 12мб? чо-то слабо верю. одна только скопмиленная либа на гошечке будет как раз 12мб размером, т.к. туда весь go-runtime прилинкуется.
А rust проще c++ для вас оказался ?
А подскажите, пожалуйста, как в этой архитектуре сейчас принято работать с базами данных?
С чем я лично столкнулся: у базы данных свои типы (string, int'ы разные, дата-время и так далее), у нативного языка - свои, у js - свои. В итоге постепенно пришёл к тому, чтобы подружить js и базу данных напрямую, оставив одну конвертацию типов вместо двух, и всю бизнес-логику перенёс в js. Но такое странное ощущение осталось, потому что js и веб вроде бы должны выполнять чисто интерфейсные функции, а бизнес-логику хотелось бы держать отдельно от интерфейса (даже если она будет написана на том же языке). Но и дублирования хотелось бы как-то избежать (модель данных в js / модель данных в нативном языке / структура данных в DB). Как это нормальные люди делают?
Базы данных бывают разные, не одним SQL как говорится, потому тебе в любом случае потребуется промежуточное звено перед базой данных, но есть плюс большая часть таких адаптеров уже написана для большинства языков. И получается, что созданный тобой картеж данных легко через адаптер трансформируется в форматы базы данных. Можно конечно и на более низком уровне, самому написать адаптер. Также есть ORM всякие (я их правда не уважаю, за избыточность) для SQL сильно упрощает жизнь.
Что касается JS тут мастхев JSON, удобней без заморочек, но если бинарный поток то я думаю ты не будешь его в базу данных складывать, а уже в какое-нибудь S3 хранилище.
Итого главная структура данных в основном обработчике, дальше адаптеры, плюсы есть например в GO там можно писать структуры json и не париться с конвертацией. Почему так? Почему в основном обработчике - потому что сегодня ты хранишь данные в SQL а завтра решишь что скорости не хватает и решишь переехать на Redis или еще что-то модное.
Ну чтобы упростить жизнь можно использовать JSON везде и выбрать соответствующую базу данных например mongodb. Да это может быть не так эффективно и будет проигрывать на больших объемах всяким мапера, но за-то жизнь себе ты сильно облегчишь как разработчик.
Ну вот да, я пробовал "везде json", но оказалось, что в C++ офигеть как неудобно работать с json. Пробовал и ORM-стайл, но и там свои сложности.
Интересно даже, отличается ли Rust в этом плане чем-то.
Тут можно написать ответ который потянет на отдельную статью.
Но если кратко JSON динамический формат, C++ статический в этом главная проблема, данные то строка, то null, то массив - придется писать кучу проверок, не передал поле - краш, передал больше краш. Были у меня танцы с этим языком не люблю его.
В Rust с этим проще пишешь структуру, что в нее не помещается просто отбрасывается. Однако нужно заранее подумать где может быть null, где может не быть поля, где нужен enum.
Итого в этих двух языках для нормально работы с JSON нужен слой нормализации. В C++ это чуть сложнее (для меня лично), в Rust проще.
А как вы с json в cpp работали? rapid_json какой-нибудь?
Можно заложить бизнес логику на саги (акторы) ими удобно управлять и легко настраивать, если саг много можно легко настроить runtime runner и runtime processor для live, а на клиента выводить через проекции, если бинарный формат, то через array u8, таури нативно поддерживает, не придётся упаковывать через base64. Клиент лучше не связывать с БД на прямую, иначе может случиться проблема с гонками. По факту сколько всего перепробовал на сегодня самым идеальным вариантом как для мобильных устройств так и для десктоп считаю таури, практически ничего в приложении менять не нужно, клиент работает на вебе, никакого react native, сам использую в основном vite + solid!
Tauri всё равно будет тащить движок хромиума в <Win10. Плюс ко всему, стабильность тоже будет под вопросом, когда у каждого в системе свой хромиум движок
Не тащит, он использует системный компонент MS WebView Edge
Откуда он возьмётся в семёрке-то?
https://v2.tauri.app/distribute/windows-installer/#offline-installer
В требованиях к нашему проекту мы не брали версии Windows меньше 10, там слишком много моментов и не только браузер.
Аргументация слабая. Из разряда: «Rust даже в терминал print делает быстрее»
Я не увидел аргумента кроме размера приложения почему выбран раст. Говорю это как владелец приложения на React + Electron которое принимает 7-10к rps по UDP и все это успешно успевает отрисовывать с бека на Go, блекджеком и без всяких модулей на C++
Вообще очень сложно читать статью где автор рассказывает так между делом, что его пугает race conditions «фантомные» в Go, или там null в типизированном языке при обработке json. Оно просто сводит на нет весь вывод в конце статьи потому что очевидно, что автор «не разобрался» с теми проблемами которые были и полез в новое озеро. Даже разбор технологий из разряда: ну мы попробовали, потыкали, там что-то плохо…вы себя хотите убедить в вашем выборе что он единственный верный?
rust и C++ - хорошие языки, но только порог входа там намного выше чем в Go, особенно в задачах где есть многопоточность. Про race conditions и утечку памяти я молчу, это отдельный навык уметь делать и видеть правильную структуру приложения чтобы потом все плюсы языка не оказались его недостатками.
Присоединюсь к вашему комментарию. К тому-же не понял, зачем был нужен backend. Для связи main-renderer есть пути проще.
Чтобы расставить точки над и. Вы упускаете момент в вопросах безопасности, разобрать электрон приложение на запчасти и достать от туда бизнес-логику которая имеет наивысшую ценность очень просто, потому потребовалось решение за пределами самого электрона (это что касается почему появился бек), дальше вопрос как поженить ужа с ежом так чтобы не было мучительно больно. Собственно это опыт и попытка описать процесс RND на примере одного решения.
Сделать MVP на голом электроне я смог и так, там не было каких-либо сложностей и работало все нормально. Вопрос поиска другого варианта решения, как раз этот процесс и описан в статье.
Что касается Rust и C++ тут могу сказать одно, на текущий момент по Rust я не нашел вариант как заставить его жрать память (ну конечно если прямо этим не озадачиться) в отличии от С++ в котором чуть не уследил и получите, и право Rust проще C++.
Go в свою очередь отличный язык (и там тоже есть вариант с WebView, но это тема отдельной статьи), с которым я уже давно на короткой ноге.
Но по факту хотелось прям вау! Чтобы быстро, современно, безопасно, а не старый блекджек со шлюхами.
приложение на запчасти и достать от туда бизнес-логику которая имеет наивысшую ценность очень просто
Все что имеет наивысшую ценность обычно размещается на удаленном сервере с доступом а-ля API. А если вы боитесь что условно schema уведут из приложения (структуру вашего API), то от этого не спасет Rust потому что для реверса нужен MITM и 3-5 минут времени, а не HEX редактор. Периодически приходится реверс делать, даже виртуалка для этого есть специальная. Так что ничего я не упускаю, просто нет смысла об этом думать.
Целесообразнее не софт переписывать на незнакомый язык, а вкладывать силы в безопасность самого API. Это более «универсальная» защита
я не нашел вариант как заставить его жрать память
….
с которым я уже давно на короткой ноге.
Я уже понял что вы человек из серии: «говорю и сам в это верю». Команда Cloudflare публично столько шишек набило на Rust, в том числе с утечкой памяти и гонками, что ваше: «не нашел» выглядит прозаично.
По поводу Go, вот я тоже считаю что с ним на короткой ноге. Тащите рулетку, будем мерять у кого нога короче. А то у меня проблем с фантомными рейсами не бывает.
к сожалению ваш ответ подтверждает мои догадки, что знания у вас довольно поверхностные. RD от этого становится еще слабее.
PS: спасибо, хоть узнал что електрон можно разобрать. Хотя все равно при задаче вытащить schema пойду по пути МИТМ, сразу логику собираешь и не надо в коде копаться. Кстати чатгпт подсказывает что електрон можно защитить от этого
Давайте по сути:
Про "самое ценное на сервере". Согласен, но при условии что приложение подразумевает серверную часть. Мой тезис в статье был не "спрятать API", а снизить поверхность атаки и цену ошибок в клиенте, когда требования по безопасности вылезают за рамки "форма + таблица".
Про "schema уведут за 3–5 минут через MITM". Иногда да, но схема API не должна быть “секретом” как механизм безопасности. API держится на авторизации, лимитах, политиках и прочем. А "3-5 минут" зависит от условий.
Почему я вообще трогал тему "вытащить логику из Electron". Electron действительно можно разобрать, почти как любой клиент. Проблема не в "декомпиляции как таковой", а в том, что при росте требований Electron начинает толкать туда, где цена ошибки выше: нативные аддоны, локальные сервисы, IPC, безопасность рендерера и т.п. Я в статье прямо описывал, что локальный бэкенд сам по себе добавляет угроз. Tauri в этом месте дал мне более собранную модель.
Про "Rust не спасёт" и "Cloudflare набили шишек". Rust закрывает другой класс рисков: memory safety и гонки (в safe-коде), но не отменяет логические ошибки и плохую архитектуру.
Про мою фразу "не нашёл как заставить Rust жрать память". Да, формулировка была слишком резкая. Rust тоже может течь, просто по другому.
Про личные оценки ("поверхностные знания" и "рулетку"). Обсуждать предлагаю технологии и модель угроз. Рулетку оставим строителям, у них хотя бы допуски прописаны.
Сразу оговорюсь: это не попытка доказать, что «Electron — зло»
Вообще-то electron действительно зло.
От Electron к Tauri: как я пересобрал архитектуру десктоп-приложения и почему Rust оказался к месту