<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Frontend on Coderrob</title><link>https://coderrob.com/tags/frontend/</link><description>Recent content in Frontend on Coderrob</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 01 Mar 2023 18:00:00 -0600</lastBuildDate><atom:link href="https://coderrob.com/tags/frontend/index.xml" rel="self" type="application/rss+xml"/><item><title>Decoupling UI Copy From API Error Contracts</title><link>https://coderrob.com/posts/decoupling-ui-messaging-from-backend-error-codes-in-web-applications/</link><pubDate>Wed, 01 Mar 2023 18:00:00 -0600</pubDate><guid>https://coderrob.com/posts/decoupling-ui-messaging-from-backend-error-codes-in-web-applications/</guid><description>&lt;p&gt;Users need human-readable error messages. Software needs stable, machine-readable error identifiers.&lt;/p&gt;
&lt;p&gt;Neither should have to parse the other.&lt;/p&gt;
&lt;p&gt;That is the boundary I want when building error handling for a web application. The backend should explain &lt;strong&gt;what failed&lt;/strong&gt; in a predictable structure. The presentation layer should decide &lt;strong&gt;how that failure is presented&lt;/strong&gt; to the person trying to finish a task.&lt;/p&gt;
&lt;p&gt;In a smaller application, that presentation layer may be the browser. In an enterprise application, it may include a backend for frontend (BFF), a shared message catalog, or a localization service. The deployment diagram can change without changing the boundary.&lt;/p&gt;</description></item></channel></rss>