Hacker News Reader

> PHP front end

Do you mean that you are fetching data from an internal API and sending server-rendered HTML response to the browser? I always naively thought GitHub worked this way. Build a GraphQL/REST API that exposes all of your system's internals, query/mutate through it and send an HTML response in the "frontend" (Ruby on Rails etc.). Frontend, but in terms of an application server that in turn accesses everything through an internal API.

View on HN

Fetching and collating data from multiple other APIs, then creating server-rendered HTML responses to the browser.

Most of the Javascript was not for interaction, but for serving ads, really.

Interestingly enough, assuming you use React this is how I see the role of something like Remix[0], which serves as a "rendering layer" that aggregates application data from different API's/stores and then sends a cachable HTML representation to the client which is thereafter hydrated.

It's not quite a backend and it's not quite a frontend, but it sort of sits in the middle and (hopefully) helps you achieve lower latency. I haven't used it myself but I think it's a promising idea and based on your post I gather a similar concept worked very well for you.

0: https://remix.run/

Reply on news.ycombinator.com