4 ms·

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 loa

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.

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.