3 ms·
every other API is basically unimportant and arbitrary Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Si
by wruza 4y ago
every other API is basically unimportant and arbitrary
Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Since for a user the page is always in sync with its server, this api is an implementation detail as much as any other internal api (e.g. between service processes or between async-threads)
Why do you think that the project separation is unavoidable in this case? E.g. some of my sites are simple express apps serving scripts and resources. I don’t have integrated build pipelines there because… well, that is exactly my concern. There seems to be no reason that we couldn’t have an ~isomorphic project with multiple entry points on multiple “ends” and a single build system for all of them.
- pas 4y agoI don't think it's unavoidable, but in practice it is two separate components with markedly different concerns and trade offs. For example if we don't use any client side JS, use only a templating system, it becomes easy to keep it one project. Eg. there's NextJS, which is a bundle of React and a NodeJS backed in one project. (And while it provides a getStaticProps and other gimmicks it doesn't really do much to make client-server state sync seamless. I still have to manually write the /api stuff.)