<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Architecture on Build in Public</title><link>https://build.ralphmayr.com/tags/architecture/</link><description>Recent content in Architecture on Build in Public</description><generator>Hugo</generator><language>en-us</language><copyright>©️ Ralph Mayr 2026</copyright><lastBuildDate>Mon, 25 Aug 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://build.ralphmayr.com/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>State diagrams are fun!</title><link>https://build.ralphmayr.com/posts/56-state-diagrams-are-fun/</link><pubDate>Mon, 25 Aug 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/56-state-diagrams-are-fun/</guid><description>&lt;p&gt;One would think that poketto.me is so straightforward that any kind of architectural documentation would be unnecessary. But then...&lt;/p&gt;
&lt;p&gt;Whenever a user saves something, the app first fetches the raw content from the relevant webpage. Then, the content undergoes an asynchronous 'cleanup' process (as I mentioned previously, I use an LLM to fix broken formatting, etc.). If the user has turned on that setting, the content is then translated. This already results in five different states that a Save can be in: New (no content available yet), Extracted (raw content available), Processing (raw content cleaned up), Translating (content being translated), and 'None' (everything done). Of course, the frontend needs to be mindful of what to allow the user to do in each of these states.&lt;/p&gt;</description></item></channel></rss>