3 ms·

The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so m

The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.

dsego 6y ago
The backend here _is_ your frontend. Nothing stopping you from adding another service layer behind it.
- antoineMoPa 6y ago
  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.
clarkevans 6y ago
In many one-off applications there's no real need to create a separate API, tight coupling lets you focus on an MVP without having to focus on abstracting out an intermediate model -- you could go from the SQL database right to HTML rendering.
dangoor 6y ago
If you have a frontend that is entirely dependent on data from the backend to display something to the user, then you've already got high coupling between the two. You probably wouldn't use this for a drawing app. But if you've got something where you're showing/updating database data, this model is likely fine.

The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.

dsego 6y ago

The backend here _is_ your frontend. Nothing stopping you from adding another service layer behind it.

antoineMoPa 6y ago
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.

clarkevans 6y ago

In many one-off applications there's no real need to create a separate API, tight coupling lets you focus on an MVP without having to focus on abstracting out an intermediate model -- you could go from the SQL database right to HTML rendering.

dangoor 6y ago

If you have a frontend that is entirely dependent on data from the backend to display something to the user, then you've already got high coupling between the two. You probably wouldn't use this for a drawing app. But if you've got something where you're showing/updating database data, this model is likely fine.