Don't build a general-purpose API to power your own front end

#102 · 🔥 127 · 💬 104 · 9 days ago · max.engineer · hakunin
How to collect all the data needed to render a page. For two, you are now free to decide "I want page a" and then implement "Page a" in the backend, and in the frontend. No more "What API workflows do we need to introduce to sort of make this page possible almost? 🤔". You can keep "Page a" dumb to only do what it needs to do. You can cache the entire JSON payload of "Page a". Frontend knows exactly what each field in "Page a" payload is for. When a stakeholder tells you to change "Page a" you will be able to literally go ahead and change "Page a", instead of spending meetings figuring out how your backend API could accommodate the change in "Page a". It's not a choreographed conglomeration of API requests. It's just "Page a". You have freed yourself from self-imposed limitations of your API. Your business logic has now moved from being haphazardly split between frontend and backend into just backend. My frontend is a SPA, so it almost always needs data snippets, not entire pages.
Don't build a general-purpose API to power your own front end



Archive | Send Feedback | WebAssembly Version (beta)