<story><title>Don’t build a general purpose API to power your own front end (2021)</title><url>https://max.engineer/server-informed-ui</url></story><parent_chain><item><author>hakunin</author><text>One extra thing I have confirmed after writing this article: it&amp;#x27;s usually a bad idea to reuse back-end data in multiple places on the front-end.&lt;p&gt;If you think about functions or object constructors in general, it kind of makes sense. One of the most important architectural practices I&amp;#x27;ve ever discovered is: don&amp;#x27;t pass in the parameters that you have, pass in the parameters that the function needs. So if you have companyName, and you are constructing a page that has a title, you shouldn&amp;#x27;t pass it companyName: companyName, you should pass it pageTitle: companyName (parameter name: parameter value). It&amp;#x27;s crucial that the parameter is named after what is needed, not what you have. This is kind of the essence of what the article is suggesting.&lt;p&gt;If your front-end is reusing a lot of fields from back-end, it&amp;#x27;s likely that you&amp;#x27;re passing it what you have in your database&amp;#x2F;resources, and not what it needs — fields for constructing the UI, configuring the views. Moreover, I rarely see front-end going through the exercise of defining exactly what they need. The article encourages more of that.&lt;p&gt;Once the front-end starts reusing the generic back-end fields everywhere, you lose track of your use-cases. Everything you ship from the back-end becomes potentially important for mysterious reasons that not even front-end can easily understand anymore. Front-end already built complex dependency trees based on these generic fields. If you actually untangle these trees, it might turn out that your front-end can only exist in 5 different &amp;quot;modes&amp;quot;, but you can no longer see that in the tangled mess. You can no longer streamline and optimize these 5 configurations.&lt;p&gt;So to summarize: pass what is needed, not what you have is a good general architectural rule that&amp;#x27;s also applicable between back-end and front-end.</text></item></parent_chain><comment><author>jmilloy</author><text>This and the article strike me initially as completely wrong, which makes it very interesting. I still want a clear separation between the &amp;quot;model&amp;quot; and the &amp;quot;view&amp;quot;, and I guess I tend to assume that this corresponds to the front-end and back-end. Maybe that&amp;#x27;s a poor assumption.&lt;p&gt;What I see here is that the &amp;quot;view&amp;quot; is split across the front-end and the back-end. Or in other words, the back-end contains both the model and the JSON API as a view. I think this is what is meant by &amp;quot;I suggest you stop treating your frontend as some generic API client, and start treating it as a half of your app.&amp;quot;&lt;p&gt;I still want a clean separation between the model, e.g. companyName, and the view, e.g. pageTitle. Somewhere, there needs to be the explicit logic (in the back-end part of the view) that says that the the pageTitle for page A is the companyName. It&amp;#x27;s okay for many different views to &amp;quot;reuse&amp;quot; fields from the model, but each view should have its own front-end and back-end components. That the view is split across a front-end&amp;#x2F;back-end divide through the nature of the web-stack doesn&amp;#x27;t change the fact that each view should remain distinct from the other views.&lt;p&gt;So I can agree in the sense that the alternative where you create a general-purpose JSON API as a model &lt;i&gt;and&lt;/i&gt; view in the back-end, and then essentially code up an &lt;i&gt;additional&lt;/i&gt; model and view for each front-end page&amp;#x2F;element with logic to convert the API data into the necessary content is a waste of time.</text></comment>
<story><title>Don’t build a general purpose API to power your own front end (2021)</title><url>https://max.engineer/server-informed-ui</url></story><parent_chain><item><author>hakunin</author><text>One extra thing I have confirmed after writing this article: it&amp;#x27;s usually a bad idea to reuse back-end data in multiple places on the front-end.&lt;p&gt;If you think about functions or object constructors in general, it kind of makes sense. One of the most important architectural practices I&amp;#x27;ve ever discovered is: don&amp;#x27;t pass in the parameters that you have, pass in the parameters that the function needs. So if you have companyName, and you are constructing a page that has a title, you shouldn&amp;#x27;t pass it companyName: companyName, you should pass it pageTitle: companyName (parameter name: parameter value). It&amp;#x27;s crucial that the parameter is named after what is needed, not what you have. This is kind of the essence of what the article is suggesting.&lt;p&gt;If your front-end is reusing a lot of fields from back-end, it&amp;#x27;s likely that you&amp;#x27;re passing it what you have in your database&amp;#x2F;resources, and not what it needs — fields for constructing the UI, configuring the views. Moreover, I rarely see front-end going through the exercise of defining exactly what they need. The article encourages more of that.&lt;p&gt;Once the front-end starts reusing the generic back-end fields everywhere, you lose track of your use-cases. Everything you ship from the back-end becomes potentially important for mysterious reasons that not even front-end can easily understand anymore. Front-end already built complex dependency trees based on these generic fields. If you actually untangle these trees, it might turn out that your front-end can only exist in 5 different &amp;quot;modes&amp;quot;, but you can no longer see that in the tangled mess. You can no longer streamline and optimize these 5 configurations.&lt;p&gt;So to summarize: pass what is needed, not what you have is a good general architectural rule that&amp;#x27;s also applicable between back-end and front-end.</text></item></parent_chain><comment><author>jlawson</author><text>It&amp;#x27;s an example of the general rule to name&amp;#x2F;implement functions according to what they do, not how they&amp;#x27;re used.&lt;p&gt;Stated another way, when building a tool, don&amp;#x27;t let information about the incidental context leak into the design of the tool itself. It should be designed to serve its intended purpose independent of when, how, where, or why it was built. This way, it won&amp;#x27;t break when that context changes, or when it&amp;#x27;s used in a new context.</text></comment>