[{"data":1,"prerenderedAt":57},["ShallowReactive",2],{"case-dev-build-log-sqljs-to-better-sqlite3-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-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",false,"DevPeek dev log: moving capture storage from sql.js to native SQLite—fixing memory growth and list lag on all-day debugging sessions.","dev-build-log",1,"\u003Ch2>The pitfall: long proxy sessions wore us down before the machine did\u003C\u002Fh2>\n\u003Cp>DevPeek is meant for debugging, not “capture three requests and quit.” Many people leave the proxy on while a phone or WebView keeps sending traffic—thousands of rows in the list, scrolling back to something captured hours ago in the Debug tab.\u003C\u002Fp>\n\u003Cp>Since v1.1.4, capture history is \u003Cstrong>saved locally\u003C\u002Fstrong> so you still see recent traffic after restart; script-processed headers and bodies are kept too. Collaboration messages, Debug tab Network entries, and resend history also needed to stick around.\u003C\u002Fp>\n\u003Cp>At first we used \u003Cstrong>SQLite compiled to JavaScript\u003C\u002Fstrong> (sql.js, common for in-browser storage). Easy to wire up, no native OS pieces—fine while the feature set was small.\u003C\u002Fp>\n\u003Cp>Once real debugging sessions got busy, the cracks showed.\u003C\u002Fp>\n\u003Ch2>What it felt like: heavier and heavier—“time to restart”\u003C\u002Fh2>\n\u003Cp>If you’ve seen any of this while using DevPeek, it was likely the same class of issue:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Proxy on from morning to evening, \u003Cstrong>the app feels slower\u003C\u002Fstrong>, memory in Task Manager creeping up.\u003C\u002Fli>\n\u003Cli>With a long list, \u003Cstrong>paging, search, and opening details\u003C\u002Fstrong> hiccup now and then while Mock and breakpoints still run—like the whole machine is dragged along.\u003C\u002Fli>\n\u003Cli>You start treating “quit DevPeek when done” as \u003Cstrong>“restart because it’s been up too long.”\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>On our side the cause was: \u003Cstrong>sql.js keeps the whole database in memory.\u003C\u002Fstrong> Every new capture and every detail update meant \u003Cstrong>copying an ever-larger database\u003C\u002Fstrong> to disk on a timer—like photocopying a notebook that gets thicker every hour.\u003C\u002Fp>\n\u003Cp>More captures and fatter headers\u002Fbodies meant slower copies and higher memory spikes. The proxy was still decrypting HTTPS, running Mock, and holding breakpoints—lag stacked on lag.\u003C\u002Fp>\n\u003Cp>The list could paginate and filter, but underneath it was still “big blob in RAM, periodic full flush”—not “append one row to a file on disk.” As we added param transform, page debugging, and collaboration, \u003Cstrong>this wasn’t fixable with small tweaks\u003C\u002Fstrong>—we had picked the wrong storage model.\u003C\u002Fp>\n\u003Ch2>What we changed: native SQLite for all-day runs\u003C\u002Fh2>\n\u003Cp>We \u003Cstrong>migrated capture and collaboration storage once\u003C\u002Fstrong>, from sql.js \u003Cstrong>to native SQLite\u003C\u002Fstrong>—the same kind of local database the OS uses, written straight to disk through a native module.\u003C\u002Fp>\n\u003Cp>The goal was simple: \u003Cstrong>performance and memory.\u003C\u002Fstrong> DevPeek should \u003Cstrong>run continuously all day with no memory pressure.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>After the change, writes work differently:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C\u002Fth>\n\u003Cth>Before (sql.js)\u003C\u002Fth>\n\u003Cth>Now (native SQLite)\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Where data mostly lives\u003C\u002Ftd>\n\u003Ctd>RAM, growing\u003C\u002Ftd>\n\u003Ctd>Local database files\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>How saves work\u003C\u002Ftd>\n\u003Ctd>Periodic full copy to disk\u003C\u002Ftd>\n\u003Ctd>One row at a time, patch in place\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>All-day sessions\u003C\u002Ftd>\n\u003Ctd>Memory climbs, occasional freezes\u003C\u002Ftd>\n\u003Ctd>Flat memory, responsive list\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>\u003Cstrong>Proxy on all day, list still scrolls, Mock still clicks\u003C\u002Fstrong>—without restarting out of habit because it’s getting sluggish.\u003C\u002Fp>\n\u003Cp>Native modules cost us extra packaging work each release—we pay that because DevPeek is meant to \u003Cstrong>sit in the background through a full debugging day\u003C\u002Fstrong>, not choke on storage.\u003C\u002Fp>\n\u003Ch2>What you should notice after the change\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>More history kept\u003C\u002Fstrong>: per-database capture cap went from about \u003Cstrong>1200 to 5000\u003C\u002Fstrong> rows (oldest still trimmed so it doesn’t grow forever).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Separate stores per feature\u003C\u002Fstrong>: capture, collaboration, Debug Network, and resend history don’t drag each other down.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Long sessions with less worry\u003C\u002Fstrong>: the pitfall we hit was memory and lag over time; after the storage swap we can honestly say DevPeek is built to \u003Cstrong>stay up all day\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If an older build felt like “gets slower until I restart,” try a current version on a long session. Still seeing issues? \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FGYPengDev\u002Fdevpeek\u002Fdiscussions\">GitHub Discussions\u003C\u002Fa>—roughly how long you leave it on and how many rows in the list helps us compare notes.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>For how the capture list and history work, see \u003Ca href=\"\u002Fen\u002Fdocs\u002Fcapture\u002F\">Capture & filtering\u003C\u002Fa>. \u003Ca href=\"\u002Fen\u002F\">Download DevPeek\u003C\u002Fa> and leave the proxy up through a real debugging day.\u003C\u002Fp>\n",{"items":14},[15,16,24,30,38,44,51],{"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":22,"seriesOrder":23},"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",2,{"slug":25,"title":26,"summary":27,"date":28,"featured":8,"seoDescription":29,"series":22,"seriesOrder":11},"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":31,"title":32,"summary":33,"date":34,"featured":35,"seoDescription":36,"series":37,"seriesOrder":23},"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":39,"title":40,"summary":41,"date":42,"featured":35,"seoDescription":43,"series":37,"seriesOrder":11},"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":45,"title":46,"summary":47,"date":48,"featured":35,"seoDescription":49,"series":50,"seriesOrder":23},"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":52,"title":53,"summary":54,"date":55,"featured":35,"seoDescription":56,"series":50,"seriesOrder":11},"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.",1785900957207]