4 ms·

The backend here _is_ your frontend. This supports my argument that there is tight coupling.

• dsego 6y ago
  Between what? Your frontend is serving the html/css/js, that's your frontend. You can have another background service behind it, as many layers as you want. This separation doesn't have to be at the http level.
  • antoineMoPa 6y ago
    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.