[{"data":1,"prerenderedAt":63},["ShallowReactive",2],{"case-dev-build-log-electron-to-tauri-en":3,"blog-list-en":13},{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11,"html":12},"dev-build-log-electron-to-tauri","DevPeek Architecture: Dropping Electron for Tauri","A debugging proxy shouldn't ship a whole Chromium just to open a window. We moved business logic into Core and swapped the desktop shell for Tauri—lighter installs, leaner background use, and the tray brings the UI back after you close the window.","2026-08-08",false,"DevPeek dev log: moving the desktop shell from Electron to Tauri—business stays in Core, the shell handles windows and OS features, with smaller footprint and lower resource use.","dev-build-log",2,"\u003Ch2>The shell is the last place a debugging proxy should bloat\u003C\u002Fh2>\n\u003Cp>DevPeek&#39;s core is a local proxy: HTTPS decryption, \u003Ca href=\"\u002Fen\u002Fdocs\u002Fmock\u002F\">Mock\u003C\u002Fa>, \u003Ca href=\"\u002Fen\u002Fdocs\u002Fparam-transform\u002F\">param transform\u003C\u002Fa>, breakpoints, and page debugging. That already eats CPU, holds ports, and runs for hours—the \u003Ca href=\"\u002Fen\u002Fblog\u002Fdev-build-log-sqljs-to-better-sqlite3\u002F\">previous dev log\u003C\u002Fa> covered storage changes we made specifically so the proxy could stay up all day.\u003C\u002Fp>\n\u003Cp>Early desktop builds carried extra weight: a full \u003Cstrong>Electron\u003C\u002Fstrong> stack (another Chromium) just to host the main window, tray, and a few system dialogs. The proxy was working; the shell was always resident too—Task Manager often showed &quot;the tool&quot; and &quot;the shell&quot; stacked on memory.\u003C\u002Fp>\n\u003Cp>Fine for a browser extension or something you open once in a while. For a proxy you \u003Cstrong>turn on in the morning and leave until evening\u003C\u002Fstrong>, a heavy shell becomes daily overhead.\u003C\u002Fp>\n\u003Ch2>Split business logic first, swap the shell second\u003C\u002Fh2>\n\u003Cp>We didn&#39;t &quot;delete Electron&quot; overnight. The migration came in three steps:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Business into Core\u003C\u002Fstrong>: proxy, rules, certs, config, and capture storage moved into a dedicated Core process (Gateway + engine). The UI talks to it over HTTP and WebSocket.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Tray split into Launcher\u003C\u002Fstrong> (around v1.1.7): system tray, mode switching, starting and watching Core—no longer tied to Electron&#39;s main process. Close the main window and the proxy in Core keeps running.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Thin desktop shell\u003C\u002Fstrong>: the main window only loads Core-hosted Web UI, plus window chrome, external links, file dialogs, and other OS-facing bits.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>By step three, Electron felt like overkill: business logic was already out of the shell, yet we still packaged a full Chromium for windows—and kept fighting native module ABI, antivirus false positives, and install size.\u003C\u002Fp>\n\u003Cp>From \u003Cstrong>v1.2.1\u003C\u002Fstrong>, the desktop shell is \u003Cstrong>Tauri 2\u003C\u002Fstrong>: system WebView for the same UI, \u003Cstrong>no bundled Chromium\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Ch2>What it looks like now\u003C\u002Fh2>\n\u003Cp>Launcher manages processes, Core runs the business, and the UI has two entry points—Standard mode through the Tauri shell, Lite mode through the system browser:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Layer\u003C\u002Fth>\n\u003Cth>Role\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Cstrong>Launcher\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Tray, start\u002Fstop Core, switch Lite \u002F Standard mode\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Core\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Proxy and all business capabilities\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Tauri Shell\u003C\u002Fstrong> (Standard)\u003C\u002Ftd>\n\u003Ctd>Thin desktop window: load Core URL, frameless controls, replay window, system dialogs, etc.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Browser Lite\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>System browser opens the same Core URL—no desktop shell; for when you only want the Web UI or prefer not to keep another desktop window open\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Both modes load the same Web UI. The difference is \u003Cstrong>who opens the window\u003C\u002Fstrong>—Tauri shell or a browser tab—not two product stacks. After Tauri, that split is clearer: Shell serves Standard mode only; Lite never needed embedded Chromium in the first place.\u003C\u002Fp>\n\u003Cp>Engineering-wise, the Shell tree stays small—no business logic in Rust, just windows and a few OS bridges. Capture, Mock, and cert trust still follow the paths you already know: \u003Ca href=\"\u002Fen\u002Fdocs\u002Finstall\u002F\">Install &amp; preferences\u003C\u002Fa> and \u003Ca href=\"\u002Fen\u002Fdocs\u002Fproxy-ssl\u002F\">Proxy &amp; SSL certificates\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Pitfalls while swapping shells\u003C\u002Fh2>\n\u003Cp>This wasn&#39;t a one-line packaging change. Window behavior and OS integration had to be rebuilt—otherwise the &quot;desktop app&quot; parts break first:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Maximize \u002F minimize \u002F close\u003C\u002Fstrong>: frameless controls re-wired for the new shell; after closing the main window, you should still reopen and focus from the tray.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>External links &amp; save file\u003C\u002Fstrong>: links open in the default browser; saving text uses system dialogs, not the old IPC path.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Recording replay\u003C\u002Fstrong>: local recording files must open and import into the replay window—offline review can&#39;t break because the shell changed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Install &amp; update (Windows)\u003C\u002Fstrong>: detect running processes before install, bundle required runtimes, in-app updates pull full installers—the release path had to stay solid after the shell swap.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>See \u003Ca href=\"\u002Fchangelog\u002F\">changelog 1.2.1\u003C\u002Fa> for the full list. If window behavior looks off after upgrading, check that release first.\u003C\u002Fp>\n\u003Ch2>What you should notice after the change\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Lighter shell\u003C\u002Fstrong>: the main window no longer bundles Chromium; same &quot;DevPeek running all day&quot; use, leaner background footprint.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Closing the window doesn&#39;t stop the proxy\u003C\u002Fstrong>: Launcher owns Core; closing the main window just hides the UI—open it again from the tray when you need it, closer to &quot;proxy in the background.&quot;\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Lite and Standard feel aligned\u003C\u002Fstrong>: Lite is still the same UI in a browser; Standard just uses a thinner desktop shell.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Install and update steadier\u003C\u002Fstrong>: same familiar Windows installer name and update flow, with shell size and dependencies rebuilt around Tauri.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>In short: we want DevPeek \u003Cstrong>heavy where it matters\u003C\u002Fstrong> (proxy, rules, history, debugging)—not heavy just to \u003Cstrong>show a local web page\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Ch2>Same thread as the last dev log\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"\u002Fen\u002Fblog\u002Fdev-build-log-sqljs-to-better-sqlite3\u002F\">Why we moved capture history from sql.js to native SQLite\u003C\u002Fa> tackled memory and lag over long sessions.\u003Cbr>This shell swap tackles carrying a full browser just to open a window—both aim at the same goal: \u003Cstrong>during long debugging days, the tool stays out of your way.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>If you&#39;ve upgraded from an Electron-era build, try a long session and watch memory plus close-window \u002F tray behavior. Something off? \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FGYPengDev\u002Fdevpeek\u002Fdiscussions\">GitHub Discussions\u003C\u002Fa>—OS version, Lite vs Standard, roughly how long you leave it on helps us compare notes.\u003C\u002Fp>\n\u003Ch2>Related docs\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fen\u002Fdocs\u002Finstall\u002F\">Install &amp; preferences\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fen\u002Fdocs\u002Fquick-start\u002F\">Quick start\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fen\u002Fdocs\u002Fproxy-ssl\u002F\">Proxy &amp; SSL certificates\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fchangelog\u002F\">Changelog\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Cp>\u003Ca href=\"\u002Fen\u002F\">Download the latest DevPeek\u003C\u002Fa> and try Standard mode with tray residency; or open the same UI in Lite \u002F browser mode first if you want to explore before committing to the desktop shell.\u003C\u002Fp>\n",{"items":14},[15,16,23,30,36,44,50,57],{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11},{"slug":17,"title":18,"summary":19,"date":20,"featured":8,"seoDescription":21,"series":10,"seriesOrder":22},"dev-build-log-sqljs-to-better-sqlite3","Why We Moved Capture History from sql.js to Native SQLite","Early DevPeek stored captures in JavaScript-based SQLite (sql.js); busy sessions ate RAM and stuttered the list. Native SQLite keeps memory flat so the proxy can run all day.","2026-08-05","DevPeek dev log: moving capture storage from sql.js to native SQLite—fixing memory growth and list lag on all-day debugging sessions.",1,{"slug":24,"title":25,"summary":26,"date":27,"featured":8,"seoDescription":28,"series":29,"seriesOrder":11},"mock-map-route-split-api","New API Is Live, Frontend Hasn't Shipped? Debug with Forward Rules","After a service split, the frontend still hits the old API while orders already live on the new service. DevPeek Forward Rules forward specific endpoints to the new host without code changes; if the new service isn't ready, Mock gets the page working first.","2026-07-26","Microservice integration and API host migration: use DevPeek Forward Rules for API forwarding—point old-host requests to the new service without changing the frontend. Mock when migration isn't done. Includes a hands-on demo.","api-debug-new-tricks",{"slug":31,"title":32,"summary":33,"date":34,"featured":8,"seoDescription":35,"series":29,"seriesOrder":22},"api-param-encryption-debug","H5 API Encrypted? Decrypt It On the Fly with DevPeek","Stuck with AES-encrypted API params during integration? Set the key and IV once in DevPeek Param Transform, and see plaintext automatically — you can even edit and re-encrypt on resend.","2026-07-18","Use DevPeek Param Transform to auto-decrypt AES-GCM encrypted H5 API requests. Supports two-way transform, plaintext editing, and debug replay.",{"slug":37,"title":38,"summary":39,"date":40,"featured":41,"seoDescription":42,"series":43,"seriesOrder":11},"h5-debug-console-mock","H5 Debug in Practice (2): Android WebView White Screen—From Console Remote Debug to Mock Validation","A campaign H5 white-screened on some Android devices after a button tap—all requests returned 200, but the page showed nothing. Using DevPeek Console to capture WebView runtime logs, remote eval to confirm a polyfill override, then Mock to verify the fallback UI under error conditions.","2026-07-13",true,"DevPeek H5 debug practice part 2: troubleshoot Android WebView white screen via Console remote debug to locate a JavaScript polyfill conflict, then use Mock to verify page fallback behavior under abnormal API responses.","h5-debug",{"slug":45,"title":46,"summary":47,"date":48,"featured":41,"seoDescription":49,"series":43,"seriesOrder":22},"wechat-h5-storage-debug","H5 Debug in Practice (1): WeChat H5 Local Cache—Debug It on Desktop","After switching test accounts in a WeChat official-account H5, the avatar still showed the old user—capture had the new token, stale data stayed in localStorage. This post walks through a real joint-debug case and how to view and edit localStorage, sessionStorage, and IndexedDB in WeChat WebView from your PC.","2026-07-11","DevPeek H5 debug: locate localStorage, sessionStorage, and IndexedDB cache issues in WeChat H5—compared with vConsole and remote debug, with real WebView debugging workflow.",{"slug":51,"title":52,"summary":53,"date":54,"featured":41,"seoDescription":55,"series":56,"seriesOrder":11},"why-we-built-devpeek-h5-debug","Why We Built DevPeek (2): That H5 Page in the App—Debug It on Your PC","Param transform fixed login, but the activity H5 only broke inside the App WebView. Remote debug and capture lived in different windows—so we folded mirroring and our own debug panels into DevPeek.","2026-07-10","DevPeek origin series, part 2: in-app H5 bugs that only show on real devices, the split between remote debug and capture, and how the Debug tab mirrors pages with built-in DOM, Console, and Network panels.","origin",{"slug":58,"title":59,"summary":60,"date":61,"featured":41,"seoDescription":62,"series":56,"seriesOrder":22},"why-we-built-devpeek","Why We Built DevPeek (1): HTTPS Decrypted, Body Still Gibberish","The night before a release, TLS was already open—but changing one request field still meant digging up encrypt\u002Fdecrypt scripts. That pushed us toward a proxy tool with business-layer crypto built in—and DevPeek started there.","2026-07-09","DevPeek origin series, part 1: the manual request-body encrypt\u002Fdecrypt grind—and why we set out to build a proxy tool that owns business-layer crypto.",1786418274381]