今日已更新 100 条资讯 | 累计 24386 条内容
关于我们

开发者

编程技术、框架工具、最佳实践

6769
篇文章

共 6769 篇 · 第 75/339 页

Dev.to

How I shipped structured JSON logging + Prometheus metrics with zero new dependencies

How I shipped structured JSON logging + Prometheus metrics with zero new dependencies I almost added structlog and prometheus_client to my pyproject.toml . Then I read what they actually do. Both libraries are excellent. structlog is the right call when you have a 30-engineer team shipping 50 services. prometheus_client is the right call when you have five teams of consumers scraping different metrics. For a single-author Python project with one process and one user, both are over-engineered. The 80 lines of code I would have pulled in, I can write in 200. The result: zero new runtime dependencies, full control over the output, and a smaller pip install footprint for every user. Here is what I did instead. The minimum useful observability surface A small Python service needs four things, in order of importance: Every log line is one JSON object. (No parsing for downstream tools.) Every request has a trace id. Every log line in that request carries the same trace id. (So you can grep by id and see the whole story.) Every log line goes to stderr. (So journald , Docker, and kubectl logs all see it without any extra configuration.) Every metric is exposed in Prometheus text format at a stable URL. structlog gives you #1, #2, #3 with a lot of flexibility. prometheus_client gives you #4 with a lot of flexibility. Both are about 16 MB of transitive dependencies combined. For a service that runs in a single process and exports maybe 20 metric names, the libraries are doing more work than the project. The 80-line JsonFormatter The custom logging formatter is the simplest part. The whole thing is here: import json import logging from contextvars import ContextVar from datetime import datetime , timezone _trace_id_var : ContextVar [ str | None ] = ContextVar ( " trace_id " , default = None ) class JsonFormatter ( logging . Formatter ): def format ( self , record : logging . LogRecord ) -> str : payload = { " ts " : datetime . now ( tz = timezone . utc ). isoformat (), " level

aidless 2026-07-13 23:50 👁 8 查看原文 →
Dev.to

Commerce And Secrets Without An IAP Tax

Commerce is the easiest feature in this release to misunderstand, so the first sentence has to be blunt: What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . Commerce does not replace IAP and never will. Purchases still go through Apple, Google, or the payment processor you chose. Codename One does not process the payment, does not touch the money, and does not take a percentage. PR #5300 adds infrastructure around the annoying backend work that comes after a purchase: validation, entitlement checks, subscription lifecycle, webhooks, and reporting. That backend work is real. Anyone who has shipped subscriptions knows the trap. Buying a SKU is not the same as knowing whether the user has the right to a feature right now. Renewals, grace periods, refunds, billing retry, product changes, trials, family sharing and store server notifications all show up later. The device has one view. The store has another. Your backend usually needs a third. Commerce is the optional service that turns that mess into an entitlement. Entitlements Instead Of SKU Branches Your app should not need to know every SKU that grants pro . It should ask for pro . CommerceManager cm = CommerceManager . getInstance (); cm . setAppUserId ( accountId ); if ( cm . isEntitled ( "pro" )) { unlockProFeatures (); } Purchases are still delegated to the existing Purchase API: cm . subscribe ( "pro_monthly" ); // or cm . purchase ( "remove_ads" ); After a purchase, or when the app starts, refresh off the EDT: new Thread (() -> { CommerceManager cm = CommerceManager . getInstance (); cm . refresh (); CN . callSerially (() -> { if ( cm . isEntitled ( "pro" )) { unlockProFeatures (); } }); }). start (); refresh() validates the current receipts with the cloud when the build has a build_key and commerce is enabled. In a local build or simulator, it safely falls back to the normal

Shai Almog 2026-07-13 23:39 👁 10 查看原文 →