You probably don't need a single-page app

Re:You probably don't need a single-page app by hello_moto on Sunday February 17, 2019 @04:06PM (#19186915)

> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.

In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.

[ Parent | on HN ]

Re:You probably don't need a single-page app by pault on Sunday February 17, 2019 @04:51PM (#19187138)

Hah. I just finished a huge refactor of an application where the back end developers "dramatically simplified" the business logic and architecture. What they meant is they removed all of the business logic from the back end so the client could do it instead. You might be able to tell I'm still a little bitter about that.

[ Parent | on HN ]

Re:You probably don't need a single-page app by insulanian on Monday February 18, 2019 @06:19AM (#19189970)

> In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience.

The key is to design the DTOs (which API endpoints are based on) starting from the API consumer perspective. Business logic on backend is responsible to deal with mapping of DTOs to the domain models and in turn to data access layer models.

This results in most DTOs being "flat" and easy to consume by client.

[ Parent | on HN ]

Re:You probably don't need a single-page app by jrowley on Sunday February 17, 2019 @04:31PM (#19187054)

This where technology like graphql can really shine.

[ Parent | on HN ]