LWN: Comments on "The "impossibly small" Microdot web framework" https://lwn.net/Articles/1034121/ This is a special feed containing comments posted to the individual LWN article titled "The "impossibly small" Microdot web framework". en-us Mon, 03 Nov 2025 06:20:19 +0000 Mon, 03 Nov 2025 06:20:19 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net OpenAPI or gRPC is a better path forward https://lwn.net/Articles/1044589/ https://lwn.net/Articles/1044589/ Rudd-O <div class="FormattedComment"> Actually it's perfect for that problem domain, and that S exactly how ESPHome solves that exact problem — gRPC on device (ESP / RP2040) when communicating with clients like Home Assistant. Works beautifully, is fast, and supports encryption too. <br> </div> Mon, 03 Nov 2025 01:38:26 +0000 OpenAPI or gRPC is a better path forward https://lwn.net/Articles/1034861/ https://lwn.net/Articles/1034861/ ssmith32 <div class="FormattedComment"> Better way forward for what?<br> <p> Certainly not for the problem domain covered in the article.<br> </div> Sun, 24 Aug 2025 03:10:21 +0000 OpenAPI or gRPC is a better path forward https://lwn.net/Articles/1034847/ https://lwn.net/Articles/1034847/ lyda <div class="FormattedComment"> Defining an API in OpenAPI or gRPC is better way forward because it allows developers to generate more of the application, keep clients, server and testing in sync reduces a slew of errors and reduces maintenance burdens.<br> <p> When I wrote a lot of python, frameworks like this seemed great. But there's a better way. If you define the OpenAPI definition first, you can then generate the server, you can generate all the clients, you can generate tests for the server and client, as well as fuzz tests for the server. Less common, but you can do the same with gRPC. It also allows you to more easily move from one technology to another.<br> </div> Sat, 23 Aug 2025 15:26:40 +0000