5 ms·

I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and moc

by krisrm 5y ago

I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.

simonw 5y ago
That's definitely true at the organizational level, and it's an argument with some merits. In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it! My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work.md#in-self-sufficient-independent-teams https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".
- ngcazz 5y ago
  that sounds like a mismatch between the architecture and how work is getting planned no? if the backend is in the critical path to delivering the user value of a feature then the backend and frontend engineers need to be developing (and testing) the feature together
  - lazide 5y ago
    They ALWAYS need to be building and developing the feature together or this happens. Decent API design without deep understanding of Client implementation or performance needs is nearly impossible. They generally should all be in the same team, but that often doesn’t scale. Not having them in the same team pretty much never works well though either.
ar_lan 5y ago
That's not really unique to SPAs, right? I don't know much about front-end development but I imagine you can create a front-end that is both not an SPA, and not server-rendered.
- krisrm 5y ago
  It's not about being unique, or what you can/can't do. You certainly can mock a front end with a ssr app, but it gets messy when you are building a rich client app and need to start sharing state back and forth.
mwcampbell 5y ago
Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well. [1]: https://world.hey.com/dhh/the-one-person-framework-711e6318 https://world.hey.com/dhh/the-one-person-framework-711e6318
tored 5y ago
You can still do that with SSR solution, the mocking just moves one step down, instead of mocking a JSON request you mock a class or an interface.
jamesfinlayson 5y ago
Also allowing your mobile app to use the same API as the website.

by krisrm 5y ago

simonw 5y ago

That's definitely true at the organizational level, and it's an argument with some merits. In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it! My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work.md#in-self-sufficient-independent-teams https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".

ngcazz 5y ago
that sounds like a mismatch between the architecture and how work is getting planned no? if the backend is in the critical path to delivering the user value of a feature then the backend and frontend engineers need to be developing (and testing) the feature together
- lazide 5y ago
  They ALWAYS need to be building and developing the feature together or this happens. Decent API design without deep understanding of Client implementation or performance needs is nearly impossible. They generally should all be in the same team, but that often doesn’t scale. Not having them in the same team pretty much never works well though either.

ar_lan 5y ago

That's not really unique to SPAs, right? I don't know much about front-end development but I imagine you can create a front-end that is both not an SPA, and not server-rendered.

krisrm 5y ago
It's not about being unique, or what you can/can't do. You certainly can mock a front end with a ssr app, but it gets messy when you are building a rich client app and need to start sharing state back and forth.

mwcampbell 5y ago

Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well. [1]: https://world.hey.com/dhh/the-one-person-framework-711e6318 https://world.hey.com/dhh/the-one-person-framework-711e6318

tored 5y ago

You can still do that with SSR solution, the mocking just moves one step down, instead of mocking a JSON request you mock a class or an interface.

jamesfinlayson 5y ago

Also allowing your mobile app to use the same API as the website.