5 ms·

Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hair

Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. 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.

kortilla 8y ago
You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).
- insulanian 8y ago
  I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.
hello_moto 8y ago
> 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.
- jrowley 8y ago
  This where technology like graphql can really shine.
- pault 8y ago
  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.
- insulanian 8y ago
  > 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.
dnautics 8y ago
I turned around an SPA fast because I'm only a backend developer. I wrote API endpoints only and contracted a friend to write the frontend, delivering a swaggerspec and vague ideas of what I wanted. Completed the thing in like four design meetings and one touch-up meeting. Couldn't be happier.
movedx 8y ago
> Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. It sound as though the application was a suitable candidate for an SPA and should have been developed as one to begin with?
- insulanian 8y ago
  It was not one application. Since we moved to SPA we have started multiple new applications having very different use cases.

kortilla 8y ago

You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).

insulanian 8y ago
I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.

hello_moto 8y ago

> 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.

jrowley 8y ago
This where technology like graphql can really shine.
pault 8y ago
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.
insulanian 8y ago
> 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.

dnautics 8y ago

I turned around an SPA fast because I'm only a backend developer. I wrote API endpoints only and contracted a friend to write the frontend, delivering a swaggerspec and vague ideas of what I wanted. Completed the thing in like four design meetings and one touch-up meeting. Couldn't be happier.

movedx 8y ago

> Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. It sound as though the application was a suitable candidate for an SPA and should have been developed as one to begin with?

insulanian 8y ago
It was not one application. Since we moved to SPA we have started multiple new applications having very different use cases.