3 ms·

I can't imagine developing an application this way anymore. From the article: "Rails has less to offer an API server that speaks JSON over the wire." Everythi

I can't imagine developing an application this way anymore. From the article: "Rails has less to offer an API server that speaks JSON over the wire." Everything we do works this way now (JSON over the wire). Everything is a RESTful API first. We build a UI that uses the API, but the business function is served completely from the API. Why? Because if the function is valuable, then some other program will likely want to exercise it programmatically. All of our capabilities are built to be composed programmatically by default. The additional effects this has on our organization is that we can often turn around new integrations in hours. They're all API calls. Other developers can kick the tires through fully secured Swagger UIs before a pretty application ties it together. And everything we build can be combined into multiple different UIs anywhere in our suite of applications. Every API is built with the assumption that it is out on the public internet, subject to all the security and scaling problems that entails. What it has driven us to do is get very good at standing up hardened, simple services that host a consistent API-style. We build UIs, but we assume the real value is in the functionality and the data, not in one specific form of its presentation.

lostcolony 6y ago
Less doesn't mean none. Rails (and frameworks like it) serve multiple purposes - One is serving server side rendered pages. One is providing non-functional requirements such as security (including browser based security, some of which is tied to the pages served, i.e., CSRF tokens). One is providing CRUD functionalities. The first one, and some of the conveniences of the second, you'd not benefit from. The last one, and some of the core functionalities of the second, you would. So, less to offer, but not 'nothing'.

lostcolony 6y ago

Less doesn't mean none. Rails (and frameworks like it) serve multiple purposes - One is serving server side rendered pages. One is providing non-functional requirements such as security (including browser based security, some of which is tied to the pages served, i.e., CSRF tokens). One is providing CRUD functionalities. The first one, and some of the conveniences of the second, you'd not benefit from. The last one, and some of the core functionalities of the second, you would. So, less to offer, but not 'nothing'.