> 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, yo

> 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.