I remember when this sort of thing used to be called SOA. Before that there was n-tier, before that client-server, before that people used to talk about terminals.
What has been will be again,
what has been done will be done again;
there is nothing new under the sun.
The best place to park different parts of the logic varies according to the algo-economics of the day. Right now people have fast client environments, so the balance is tipping back to heavy clients.
SOA (Service-oriented architecture) is a pattern to split an application into discrete pieces of software providing application functionality as services to other applications.
Fat vs Thin is more over a debate about where to place logic. Thin implies controllers are small, and models have a wider responsibility. Fat is the inverse, where controller do the majority of work, and models are a small abstraction.
My point is this: They are not the same thing. SOA helps in designing scalable, robust systems. Fat vs Thin helps you decide where logic should go.
Well, unless you design them for high performance from the very beginning, SOA also helps in building slow systems that your customers will hate and that will fail in the marketplace if the people who buy the software actually use it.
(I was at Altassian's San Francisco office a few months ago and I said half-jokingly that I quit my last job because I couldn't stand waiting for Confluence, and all the other off-brand webapps my employer used, to load.)
Now I use Github, which offers true interactive performance even over crappy DSL connections. I'm not going to work for anybody who makes me use some off-brand webapp that makes me wait 30 seconds to put time on a ticket or to edit a Wiki page.
SOA can be part of the solution rather than the problem, but it takes a clear architectural view from day one and a commitment to avoid stupid and obvious mistakes, as the article points out.
Not sure why you're blaming SOA there. Atlassian apps are standalone instances so, assuming your former employer self-hosts, it has more to do with your own server and network performance.
In fact GitHub is most likely closer to SOA architecture than Confluence is.
And whether it is SOA or not, the moral is that many many systems are designed and sold as if performance didn't matter.
I had another job where the team toiled for years to develop an SOA system that, when we first stacked it all up, took 45 minutes to boot up an RIA because it did 50,000 requests to initialize it's state.
Sure, this is stupid design, but people do this all the time.
I was able to speed the boot time to 20 seconds by packing much of the data with the application file and creating one "initialize" call that downloaded all of the data necessary to initialize a particular instance of he app in one shot.
Had performance been built into the app from day one that app might have seen the light of day.
Fat vs. Thin does not apply to a specific topic. Fat vs. Thin can apply to controllers and models, but that's an exhausted argument, in models code is more reusable, fat controllers are, in my experience, the most obvious symptom of not understanding DRY principles and of not having good conventions and architecture. In the client-server realm, fat vs. thin is about how much code to run on the client side, i.e. how much javascript to deliver, how much of the UI is handled by the client before the server is bothered.
You can have a thin server with fat controller methods, or vice-versa. The point is the fat vs. thin battle happens in a lot of different areas, not just controllers.
I came in here to find exactly this position, and I agree with you 100%.
What I think, as an aged software developer who has watched it all evolve, multiple times over, is that there really and truly is a software generation gap, whereby students of newly minted Comp-Sci'ish "Status-"Education Curricula are suddenly thrust upon the world, to do things new.
The problem is that too much studying is going on, and thus ignorance of actual industry predisposes re-invention. If Comp-Sci students started at 18 as junior programmers (like the good ol' days, before there were such things as Computer sections in bookstores..) and just got immediate practical experience across a broad swath of industrial computing applications, there'd be a lot more comprehension, on the part of the student, of just how much has been implemented in the Big World.
Its not a bad thing that there is all this sudden New School re-invention of long-abandoned tools and widgets, its just that there's an awful lot of grommets involved in the cultivation of it all, and sometimes .. yes kids, things do get 're-discovered' and pitched as 'newly invented and described here for the first time, ever, on this blog!' when perhaps a little actual investigation would lead the adventure to realize they were in fact already in well charted territories.
Its amusing, though, to see "API-first is what we call it" generate yet another word in the big, tempestuous, incestuous cloud that is Computing ..
The truism is this: those who ignore history are liable to repeat it. This works in code thus: if you haven't got an implementation, implement. Dodgy stuff, that 'got'.
