Don’t build a general purpose API to power your own front end (2021)
One extra thing I have confirmed after writing this article: it&#x27;s usually a bad idea to reuse back-end data in multiple places on the front-end.<p>If you think about functions or object constructors in general, it kind of makes sense. One of the most important architectural practices I&#x27;ve ever discovered is: don&#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&#x27;t pass it companyName: companyName, you should pass it pageTitle: companyName (parameter name: parameter value). It&#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.<p>If your front-end is reusing a lot of fields from back-end, it&#x27;s likely that you&#x27;re passing it what you have in your database&#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.<p>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 &quot;modes&quot;, but you can no longer see that in the tangled mess. You can no longer streamline and optimize these 5 configurations.<p>So to summarize: pass what is needed, not what you have is a good general architectural rule that&#x27;s also applicable between back-end and front-end.