4 ms·

Let's say you take another approach. Build a backend that serves REST, GraphQL or whatever protocol. This can be a Rails backend, could be Python, JS, whatever.

Let's say you take another approach. Build a backend that serves REST, GraphQL or whatever protocol. This can be a Rails backend, could be Python, JS, whatever. Now you or the frontend team are free to build the frontend with whatever technology. You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend. Also, if your client/boss asks you to build a native IOS frontend, you already have built an API, useful no?

deleted 6y ago
[deleted]
dsego 6y ago
> You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend. With proper architecture, you would have stores & services as the main boundary of your app. Then you can easily consume them in your server-side rendered pages or JSON API endpoints, which are then just thin wrappers. >Also, if your client/boss asks you to build a native IOS frontend, you already have built an API, useful no? My client wanted email forms to improve engagement. And it was not a theoretical request.