GPT 5.2 codex для ревью, Gemini 3.0 pro для написания документации, Opus 4.5 для разработки. Использую как подписки так и GitHub Copilot, но модели те же. В основном использую opencode, в последнее время его сильно прокачали и да он умеет работает с подписками, а не только с API.
После статьи времени прошло много и OpenCode сильно прокачали свое решение, Droid же сильно ушел в направление корпоративной (командной) разработки. Claude Code тоже обновился скилы, маркет и т.п.
В последнее время я чаще использую opencode (нативная поддержка подписки Anthropic и Copilot подкупает). Часто тебе нужно что-то закончить, а лимиты закончились, переключаюсь на другую модель или другого провайдера и вперед. У Claude Code есть свои очень прикольные штуки в виде скилов и т.п..
Идеального рецепта не существует, мир меняется очень быстро. Однако если есть подписка от Anthropic и больше ничего, идти в другие решения нет никакого смысла.
Про "самое ценное на сервере". Согласен, но при условии что приложение подразумевает серверную часть. Мой тезис в статье был не "спрятать API", а снизить поверхность атаки и цену ошибок в клиенте, когда требования по безопасности вылезают за рамки "форма + таблица".
Про "schema уведут за 3–5 минут через MITM". Иногда да, но схема API не должна быть “секретом” как механизм безопасности. API держится на авторизации, лимитах, политиках и прочем. А "3-5 минут" зависит от условий.
Почему я вообще трогал тему "вытащить логику из Electron". Electron действительно можно разобрать, почти как любой клиент. Проблема не в "декомпиляции как таковой", а в том, что при росте требований Electron начинает толкать туда, где цена ошибки выше: нативные аддоны, локальные сервисы, IPC, безопасность рендерера и т.п. Я в статье прямо описывал, что локальный бэкенд сам по себе добавляет угроз. Tauri в этом месте дал мне более собранную модель.
Про "Rust не спасёт" и "Cloudflare набили шишек". Rust закрывает другой класс рисков: memory safety и гонки (в safe-коде), но не отменяет логические ошибки и плохую архитектуру.
Про мою фразу "не нашёл как заставить Rust жрать память". Да, формулировка была слишком резкая. Rust тоже может течь, просто по другому.
Про личные оценки ("поверхностные знания" и "рулетку"). Обсуждать предлагаю технологии и модель угроз. Рулетку оставим строителям, у них хотя бы допуски прописаны.
Чтобы расставить точки над и. Вы упускаете момент в вопросах безопасности, разобрать электрон приложение на запчасти и достать от туда бизнес-логику которая имеет наивысшую ценность очень просто, потому потребовалось решение за пределами самого электрона (это что касается почему появился бек), дальше вопрос как поженить ужа с ежом так чтобы не было мучительно больно. Собственно это опыт и попытка описать процесс RND на примере одного решения.
Сделать MVP на голом электроне я смог и так, там не было каких-либо сложностей и работало все нормально. Вопрос поиска другого варианта решения, как раз этот процесс и описан в статье.
Что касается Rust и C++ тут могу сказать одно, на текущий момент по Rust я не нашел вариант как заставить его жрать память (ну конечно если прямо этим не озадачиться) в отличии от С++ в котором чуть не уследил и получите, и право Rust проще C++.
Go в свою очередь отличный язык (и там тоже есть вариант с WebView, но это тема отдельной статьи), с которым я уже давно на короткой ноге.
Но по факту хотелось прям вау! Чтобы быстро, современно, безопасно, а не старый блекджек со шлюхами.
Тут можно написать ответ который потянет на отдельную статью.
Но если кратко JSON динамический формат, C++ статический в этом главная проблема, данные то строка, то null, то массив - придется писать кучу проверок, не передал поле - краш, передал больше краш. Были у меня танцы с этим языком не люблю его.
В Rust с этим проще пишешь структуру, что в нее не помещается просто отбрасывается. Однако нужно заранее подумать где может быть null, где может не быть поля, где нужен enum.
Итого в этих двух языках для нормально работы с JSON нужен слой нормализации. В C++ это чуть сложнее (для меня лично), в Rust проще.
Базы данных бывают разные, не одним SQL как говорится, потому тебе в любом случае потребуется промежуточное звено перед базой данных, но есть плюс большая часть таких адаптеров уже написана для большинства языков. И получается, что созданный тобой картеж данных легко через адаптер трансформируется в форматы базы данных. Можно конечно и на более низком уровне, самому написать адаптер. Также есть ORM всякие (я их правда не уважаю, за избыточность) для SQL сильно упрощает жизнь.
Что касается JS тут мастхев JSON, удобней без заморочек, но если бинарный поток то я думаю ты не будешь его в базу данных складывать, а уже в какое-нибудь S3 хранилище.
Итого главная структура данных в основном обработчике, дальше адаптеры, плюсы есть например в GO там можно писать структуры json и не париться с конвертацией. Почему так? Почему в основном обработчике - потому что сегодня ты хранишь данные в SQL а завтра решишь что скорости не хватает и решишь переехать на Redis или еще что-то модное.
Ну чтобы упростить жизнь можно использовать JSON везде и выбрать соответствующую базу данных например mongodb. Да это может быть не так эффективно и будет проигрывать на больших объемах всяким мапера, но за-то жизнь себе ты сильно облегчишь как разработчик.
Оба решения тестировались на подписках от Claude (sonnet 4.5) и Zai (glm-4.6). Мог бы в обзор добавить и claude code, однако мне показалось это неправильно потому как этот инструмент заточен на одного вендора - т.е. вы не можете легко переключиться c sonnet на glm , а подключить модели от OpenRoute вообще никак.
В процессе тестирования также использовал Proxy чтобы анализировать системные промты, скажу сразу они не сильно отличаются (не так чтобы я разбирал их до глубоко), но у droid они чуть лучше структурированы.
В свое время я проводил подобное тестирования сравнивая Cline, Kilo Code, Roo code (ide) с opencode (cli). И у решений на IDE был зверский аппетит на токены.
Сейчас почти каждую неделю появляются бесплатные модели, да они иногда слабенькие, но иногда очень даже ничего. Но для работы с ними нужен агент и тут в статье я попытался объяснить почему два весьма неплохих решения не совсем одинаково работают. Потому как задачи сложные и требуют много шагов, если вдруг происходит сбой приходится объяснять модели все с нуля, а это лишнее время, токены, деньги и нервы.
Ваши представления строятся на достаточно небольших проектах, в которых видимо нет тестовой, дев и прод среды. Не прописаны регламенты вывода в прод, проведение определенных процедур для деплоя. Мысль в первую очередь в том чтобы пройти этот путь, задеплоить сервис и при необходимости быстро менять бизнес процессы (в определенных пределах конечно) и не ждать 1-2 спринта пока изменения появятся на проде. Использование bpmn решает эту задачу т.е. ускоряя time-to-market практически до минут, а не дней и недель.
Если у вас коротки процесс вывода в прод и бизнес логика примитивна (простая), bpmn вам только помешает и не предоставит тех возможностей о которых я говорил.
Насчет PG - все просто попробуйте его нагрузить 100к параллельными запросами и потом я готов обсудить как вы себя чувствуете после этого, как вырос SLA и т.п.
То что я описал релевантно для больших, корпоративных, высоконагруженных проектов.
У нас в проде на одном из проектов уже есть решение где BPMN вызывает функцию описанную в JAVA. Уверен что потратив немного сил на поиски вы найдете решение, я же обозначил возможность и плюсы.
Коррекцию текстов я всегда делаю через AI, чтобы избежать ошибок. При наличии такого корректора (в реальной жизни это был бы редактор) глупо, потому как в процессе написания очень часто возникает тавтология и другие стилистические ошибки.
Когда много мыслей, а хочется донести мысль не раздувая статью до уровня документации приходится чем-то жертвовать. Если быть совсем честным, любой код можно положить в гит и сделать diff, тот же C4 от drawio по факту xml как файл word или excel и да тут получается версионировать, но вот без знания структуры разметки будет сложно понять что изменилось. С UML или Structurizr попроще, но будем честны UML это про бизнес процессы, все остальное опции, рисовать там диаграммы c4 тот еще вариант. Structurizr поинтересней и чуть понятней, можно еще mermaid добавить в эту же историю. Что касается диаграммы развертывания, отличная история, но до тех пор пока не появляется георезервирование, изолированые vlan и т.п. Тут уже нотации от google поинтересней.
Все верно и потому я и предлагаю YAML из которого можно собрать любую визуализацию в том числе C4. Полагаю что при правильных танцах с бубнами можно сконвертировать и в нотации Archmate. В чем у меня лично претензии к C4 и Blocks&Lines, один слишком ограничен (не возможности указать интерфейсы), другой слишком свободен (рисуй что хочешь, понимай как хочешь). В yaml же один раз описал структуру, разложил все по полочкам, и конвертируй куда хочешь. Плюс возможно каждый модуль описать в yaml и потом, так как это машиночитаемая нотация, можешь визуализировать все связи, все интерфейсы, потоки, ограничения, протоколы и т.п. Тут прям поле для деятельности архитектора. С удовольствием бы занялся типизацией yaml и созданием редактора (конвертора), но как обычно нет времени и достойного финансирования, да и Structurizr DSL уже есть. Знаю что в больших компаниях (говорю про Россию) уже есть системы машиночитаемых нотаций, ну или зачатки этих систем. Так что будущее мне видится именно так: источник знаний один который конвертируется в любые нотации.
Ну я пытался донести эту мысль что собираем все в yaml а потом конвертируем в то что требуется в том числе в C4. C4 к сожалению имеет очень ограниченную нотацию, так не возможно обозначить интерфейсы, а их к слову может быть очень много у одного микросервиса - особенно если он является адаптером.
Думаю вам стоит попробовать самому, с нейронкой, собрать нечто подобное. Результаты вас сильно удивят.
Добавил
Отличная мысль! Обязательно соберу и добавлю.
Для анализа и сравнения тензоров - Opus 4.5, работал часа 4 без остановки.
GPT 5.2 codex для ревью, Gemini 3.0 pro для написания документации, Opus 4.5 для разработки. Использую как подписки так и GitHub Copilot, но модели те же. В основном использую opencode, в последнее время его сильно прокачали и да он умеет работает с подписками, а не только с API.
После статьи времени прошло много и OpenCode сильно прокачали свое решение, Droid же сильно ушел в направление корпоративной (командной) разработки. Claude Code тоже обновился скилы, маркет и т.п.
В последнее время я чаще использую opencode (нативная поддержка подписки Anthropic и Copilot подкупает). Часто тебе нужно что-то закончить, а лимиты закончились, переключаюсь на другую модель или другого провайдера и вперед. У Claude Code есть свои очень прикольные штуки в виде скилов и т.п..
Идеального рецепта не существует, мир меняется очень быстро. Однако если есть подписка от Anthropic и больше ничего, идти в другие решения нет никакого смысла.
Давайте по сути:
Про "самое ценное на сервере". Согласен, но при условии что приложение подразумевает серверную часть. Мой тезис в статье был не "спрятать API", а снизить поверхность атаки и цену ошибок в клиенте, когда требования по безопасности вылезают за рамки "форма + таблица".
Про "schema уведут за 3–5 минут через MITM". Иногда да, но схема API не должна быть “секретом” как механизм безопасности. API держится на авторизации, лимитах, политиках и прочем. А "3-5 минут" зависит от условий.
Почему я вообще трогал тему "вытащить логику из Electron". Electron действительно можно разобрать, почти как любой клиент. Проблема не в "декомпиляции как таковой", а в том, что при росте требований Electron начинает толкать туда, где цена ошибки выше: нативные аддоны, локальные сервисы, IPC, безопасность рендерера и т.п. Я в статье прямо описывал, что локальный бэкенд сам по себе добавляет угроз. Tauri в этом месте дал мне более собранную модель.
Про "Rust не спасёт" и "Cloudflare набили шишек". Rust закрывает другой класс рисков: memory safety и гонки (в safe-коде), но не отменяет логические ошибки и плохую архитектуру.
Про мою фразу "не нашёл как заставить Rust жрать память". Да, формулировка была слишком резкая. Rust тоже может течь, просто по другому.
Про личные оценки ("поверхностные знания" и "рулетку"). Обсуждать предлагаю технологии и модель угроз. Рулетку оставим строителям, у них хотя бы допуски прописаны.
Чтобы расставить точки над и. Вы упускаете момент в вопросах безопасности, разобрать электрон приложение на запчасти и достать от туда бизнес-логику которая имеет наивысшую ценность очень просто, потому потребовалось решение за пределами самого электрона (это что касается почему появился бек), дальше вопрос как поженить ужа с ежом так чтобы не было мучительно больно. Собственно это опыт и попытка описать процесс RND на примере одного решения.
Сделать MVP на голом электроне я смог и так, там не было каких-либо сложностей и работало все нормально. Вопрос поиска другого варианта решения, как раз этот процесс и описан в статье.
Что касается Rust и C++ тут могу сказать одно, на текущий момент по Rust я не нашел вариант как заставить его жрать память (ну конечно если прямо этим не озадачиться) в отличии от С++ в котором чуть не уследил и получите, и право Rust проще C++.
Go в свою очередь отличный язык (и там тоже есть вариант с WebView, но это тема отдельной статьи), с которым я уже давно на короткой ноге.
Но по факту хотелось прям вау! Чтобы быстро, современно, безопасно, а не старый блекджек со шлюхами.
В требованиях к нашему проекту мы не брали версии Windows меньше 10, там слишком много моментов и не только браузер.
Тут можно написать ответ который потянет на отдельную статью.
Но если кратко JSON динамический формат, C++ статический в этом главная проблема, данные то строка, то null, то массив - придется писать кучу проверок, не передал поле - краш, передал больше краш. Были у меня танцы с этим языком не люблю его.
В Rust с этим проще пишешь структуру, что в нее не помещается просто отбрасывается. Однако нужно заранее подумать где может быть null, где может не быть поля, где нужен enum.
Итого в этих двух языках для нормально работы с JSON нужен слой нормализации. В C++ это чуть сложнее (для меня лично), в Rust проще.
Базы данных бывают разные, не одним SQL как говорится, потому тебе в любом случае потребуется промежуточное звено перед базой данных, но есть плюс большая часть таких адаптеров уже написана для большинства языков. И получается, что созданный тобой картеж данных легко через адаптер трансформируется в форматы базы данных. Можно конечно и на более низком уровне, самому написать адаптер. Также есть ORM всякие (я их правда не уважаю, за избыточность) для SQL сильно упрощает жизнь.
Что касается JS тут мастхев JSON, удобней без заморочек, но если бинарный поток то я думаю ты не будешь его в базу данных складывать, а уже в какое-нибудь S3 хранилище.
Итого главная структура данных в основном обработчике, дальше адаптеры, плюсы есть например в GO там можно писать структуры json и не париться с конвертацией. Почему так? Почему в основном обработчике - потому что сегодня ты хранишь данные в SQL а завтра решишь что скорости не хватает и решишь переехать на Redis или еще что-то модное.
Ну чтобы упростить жизнь можно использовать JSON везде и выбрать соответствующую базу данных например mongodb. Да это может быть не так эффективно и будет проигрывать на больших объемах всяким мапера, но за-то жизнь себе ты сильно облегчишь как разработчик.
да, как не странно, к C++ у меня личное отрицание еще с 2010 года, возможно я просто не могу преодолеть этот барьер.
не смотрел в эту сторону и по-любому бек с фронтом нужно было как-то вязать, потому решили все переписать на Rust.
Оба решения тестировались на подписках от Claude (sonnet 4.5) и Zai (glm-4.6). Мог бы в обзор добавить и claude code, однако мне показалось это неправильно потому как этот инструмент заточен на одного вендора - т.е. вы не можете легко переключиться c sonnet на glm , а подключить модели от OpenRoute вообще никак.
В процессе тестирования также использовал Proxy чтобы анализировать системные промты, скажу сразу они не сильно отличаются (не так чтобы я разбирал их до глубоко), но у droid они чуть лучше структурированы.
В свое время я проводил подобное тестирования сравнивая Cline, Kilo Code, Roo code (ide) с opencode (cli). И у решений на IDE был зверский аппетит на токены.
Сейчас почти каждую неделю появляются бесплатные модели, да они иногда слабенькие, но иногда очень даже ничего. Но для работы с ними нужен агент и тут в статье я попытался объяснить почему два весьма неплохих решения не совсем одинаково работают. Потому как задачи сложные и требуют много шагов, если вдруг происходит сбой приходится объяснять модели все с нуля, а это лишнее время, токены, деньги и нервы.
Ваши представления строятся на достаточно небольших проектах, в которых видимо нет тестовой, дев и прод среды. Не прописаны регламенты вывода в прод, проведение определенных процедур для деплоя. Мысль в первую очередь в том чтобы пройти этот путь, задеплоить сервис и при необходимости быстро менять бизнес процессы (в определенных пределах конечно) и не ждать 1-2 спринта пока изменения появятся на проде. Использование bpmn решает эту задачу т.е. ускоряя time-to-market практически до минут, а не дней и недель.
Если у вас коротки процесс вывода в прод и бизнес логика примитивна (простая), bpmn вам только помешает и не предоставит тех возможностей о которых я говорил.
Насчет PG - все просто попробуйте его нагрузить 100к параллельными запросами и потом я готов обсудить как вы себя чувствуете после этого, как вырос SLA и т.п.
То что я описал релевантно для больших, корпоративных, высоконагруженных проектов.
У нас в проде на одном из проектов уже есть решение где BPMN вызывает функцию описанную в JAVA. Уверен что потратив немного сил на поиски вы найдете решение, я же обозначил возможность и плюсы.
Коррекцию текстов я всегда делаю через AI, чтобы избежать ошибок. При наличии такого корректора (в реальной жизни это был бы редактор) глупо, потому как в процессе написания очень часто возникает тавтология и другие стилистические ошибки.
Когда много мыслей, а хочется донести мысль не раздувая статью до уровня документации приходится чем-то жертвовать. Если быть совсем честным, любой код можно положить в гит и сделать diff, тот же C4 от drawio по факту xml как файл word или excel и да тут получается версионировать, но вот без знания структуры разметки будет сложно понять что изменилось. С UML или Structurizr попроще, но будем честны UML это про бизнес процессы, все остальное опции, рисовать там диаграммы c4 тот еще вариант. Structurizr поинтересней и чуть понятней, можно еще mermaid добавить в эту же историю. Что касается диаграммы развертывания, отличная история, но до тех пор пока не появляется георезервирование, изолированые vlan и т.п. Тут уже нотации от google поинтересней.
Все верно и потому я и предлагаю YAML из которого можно собрать любую визуализацию в том числе C4. Полагаю что при правильных танцах с бубнами можно сконвертировать и в нотации Archmate. В чем у меня лично претензии к C4 и Blocks&Lines, один слишком ограничен (не возможности указать интерфейсы), другой слишком свободен (рисуй что хочешь, понимай как хочешь). В yaml же один раз описал структуру, разложил все по полочкам, и конвертируй куда хочешь. Плюс возможно каждый модуль описать в yaml и потом, так как это машиночитаемая нотация, можешь визуализировать все связи, все интерфейсы, потоки, ограничения, протоколы и т.п. Тут прям поле для деятельности архитектора. С удовольствием бы занялся типизацией yaml и созданием редактора (конвертора), но как обычно нет времени и достойного финансирования, да и Structurizr DSL уже есть. Знаю что в больших компаниях (говорю про Россию) уже есть системы машиночитаемых нотаций, ну или зачатки этих систем. Так что будущее мне видится именно так: источник знаний один который конвертируется в любые нотации.
Ну я пытался донести эту мысль что собираем все в yaml а потом конвертируем в то что требуется в том числе в C4. C4 к сожалению имеет очень ограниченную нотацию, так не возможно обозначить интерфейсы, а их к слову может быть очень много у одного микросервиса - особенно если он является адаптером.