Re:Don’t Build a General Purpose API to Power Your Own Front...
by holoduke on Sunday August 20, 2023 @06:15AM
(#37197739)
I run a popular app (native ios and android) and a web version. I find having A single json serving api much easier to maintain. The frontends are isolated projects. The backend is just a simple layer with static data served as json. If you would have static html it means you need to update all static files whenever a ui change is needed. Makes it overly complicated. Caching becomes also a challenge and the so does the performance.
Currently just running a few Hetzner instances to serve 50k requests per second. That would be really hard with a server side rendered html.
Re:Don’t Build a General Purpose API to Power Your Own Front...
by Y-bar on Sunday August 20, 2023 @06:28AM
(#37197812)
> If you would have static html it means you need to update all static files whenever a ui change is needed. Makes it overly complicated
We do use a templating engine and separate CSS files, so no, not at all, all static files does not need updating on every change.
> Caching becomes also a challenge and the so does the performance
Not at all, not even on black fridays.
> That would be really hard with a server side rendered html.
Why do you pose that hypothetical when our real-world experience is easy?
Re:Don’t Build a General Purpose API to Power Your Own Front...
by halfcat on Sunday August 20, 2023 @08:26AM
(#37198440)
Do you build each interface with different tools (e.g. Swift, Java, and React), or one of the unifying tools (Flutter, React Native, etc)?
Re:Don’t Build a General Purpose API to Power Your Own Front...
by robertoandred on Sunday August 20, 2023 @01:23PM
(#37201140)
Then you're stuck with two kinds of templating.
Nothing prevents the main response from being served as regular HTML and subsequent XHR request for some parts of a page being JSON or some such data format. In fact I bet that sending server-side rendered HTML is faster than sending a full structured page as JSON which has to be decoded, parsed, and then converted to HTML.