TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Pattern: Back Ends for Front Ends

2 点作者 BeefySwain大约 2 年前

2 条评论

BeefySwain大约 2 年前
Read this article recently while doing additional research on the points brought up by other articles such as &quot;Don’t Build A General Purpose API To Power Your Own Front End&quot;[0] and &quot;Splitting Your Data &amp; Application APIs: Going Further&quot;[1], and found it to be very insightful.<p>[0] <a href="https:&#x2F;&#x2F;max.engineer&#x2F;server-informed-ui" rel="nofollow">https:&#x2F;&#x2F;max.engineer&#x2F;server-informed-ui</a> [1] <a href="https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;splitting-your-apis&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;splitting-your-apis&#x2F;</a>
88913527大约 2 年前
Isn&#x27;t the point of GraphQL to allow each client to select what they want? On desktop, you want fields A B C, on mobile you want fields X Y Z-- great! It goes against the &quot;don&#x27;t build a general-purpose API&quot; thought, but it works great in unlocking the front-end teams from having to request a change from the backend team. But that&#x27;s assuming you have separate front-end and back-end teams. The most useful architecture might be contextual to your organization&#x27;s size and structure.
评论 #34958290 未加载