4 ms·

Server rendered HTML is all well and good until you want to add native apps or a first class API layer. At that point, it makes more sense to have the web be ju

Server rendered HTML is all well and good until you want to add native apps or a first class API layer. At that point, it makes more sense to have the web be just another client and move as much business logic into the API layer as possible.

neeleshs 2y ago
Even with react, we have found that having a separate API layer was more ergonomic. Maybe with graphql it is different
timr 2y ago
There's absolutely nothing preventing you from emitting JSON (or whatever) API responses from the same controller logic that renders HTML. Rails makes it easy.
- ec109685 2y ago
  A native app is more than just translating each html page into a screen. You’ll likely want to build a data model that you use throughout the app, instantly load as much of the next screen from data already fetched as you can, etc. Having a flexible API tier makes that more ergonomic.
  - timr 2y ago
    Nobody said anything about translating pages into screens. The point is that the data model (and hence, the API design) applies equally to a web UI or a native application. The issues you're raising also matter for making webpages fast. When you think about the data model design before you make the presentation layer, in almost all cases, the choice of what you render is basically a straightforward transformation.
    - hombre_fatal 2y ago
      > Nobody said anything about translating pages into screens. Well, someone did. The person above them said you can just map your Rails html routes into JSON returning routes (translating pages into API endpoints). Which obviously gives you a suboptimal API since data access is tied to Rails pages instead of having a flexible, deliberate API. And once you build and have to maintain the latter along with the former, you are now duplicating work. It's a familiar issue for people who have built SSR apps.
      - timr 2y ago
        > The person above them said you can just map your Rails html routes into JSON returning routes (translating pages into API endpoints). That was me. And no, you misunderstood. I said "controller logic" -- Rails (and any other decent web framework) allows you to map routes to endpoints in the code. In the simplest case, that endpoint could be used for an API response or a webpage, and just render different things. Alternatively, you can even have API routes mapped to a slightly different top-level endpoint, which does the vast majority of its work by calling the same set of downstream methods as the webpage version. Or a thousand other variations on the theme. In short, assuming that you don't just structure your code as one gigantic function for each route, it's not hard to do, or hard to maintain. You do have to think a little bit about how the controller logic fits in with the API and the webpage structure, and I contend that this is the actual, practical reason that we've seen so much burdensome (over)use of React, GraphQL and the like -- those things are separate teams at many companies, and the "decoupling" theoretically unblocks the teams.
pjmlp 2y ago
Those that want to make it right deliver JSON as well. Those that want it easy, use Electron.
renegade-otter 2y ago
First class API layers and native apps require such a massive amount of work (and money) that your app emitting HTML is the least of your problems. This is not 2011 when every website was building an "app" for native experience. If you are not building an Uber or an AirBB, you will probably manage.

neeleshs 2y ago

Even with react, we have found that having a separate API layer was more ergonomic. Maybe with graphql it is different

timr 2y ago

There's absolutely nothing preventing you from emitting JSON (or whatever) API responses from the same controller logic that renders HTML. Rails makes it easy.

ec109685 2y ago
A native app is more than just translating each html page into a screen. You’ll likely want to build a data model that you use throughout the app, instantly load as much of the next screen from data already fetched as you can, etc. Having a flexible API tier makes that more ergonomic.
- timr 2y ago
  Nobody said anything about translating pages into screens. The point is that the data model (and hence, the API design) applies equally to a web UI or a native application. The issues you're raising also matter for making webpages fast. When you think about the data model design before you make the presentation layer, in almost all cases, the choice of what you render is basically a straightforward transformation.
  - hombre_fatal 2y ago
    > Nobody said anything about translating pages into screens. Well, someone did. The person above them said you can just map your Rails html routes into JSON returning routes (translating pages into API endpoints). Which obviously gives you a suboptimal API since data access is tied to Rails pages instead of having a flexible, deliberate API. And once you build and have to maintain the latter along with the former, you are now duplicating work. It's a familiar issue for people who have built SSR apps.
    - timr 2y ago
      > The person above them said you can just map your Rails html routes into JSON returning routes (translating pages into API endpoints). That was me. And no, you misunderstood. I said "controller logic" -- Rails (and any other decent web framework) allows you to map routes to endpoints in the code. In the simplest case, that endpoint could be used for an API response or a webpage, and just render different things. Alternatively, you can even have API routes mapped to a slightly different top-level endpoint, which does the vast majority of its work by calling the same set of downstream methods as the webpage version. Or a thousand other variations on the theme. In short, assuming that you don't just structure your code as one gigantic function for each route, it's not hard to do, or hard to maintain. You do have to think a little bit about how the controller logic fits in with the API and the webpage structure, and I contend that this is the actual, practical reason that we've seen so much burdensome (over)use of React, GraphQL and the like -- those things are separate teams at many companies, and the "decoupling" theoretically unblocks the teams.

pjmlp 2y ago

Those that want to make it right deliver JSON as well. Those that want it easy, use Electron.

renegade-otter 2y ago

First class API layers and native apps require such a massive amount of work (and money) that your app emitting HTML is the least of your problems. This is not 2011 when every website was building an "app" for native experience. If you are not building an Uber or an AirBB, you will probably manage.