

Client-Server Domain Separation - aliostad
http://byterot.blogspot.com/2012/11/client-server-domain-separation-csds-rest.html

======
csense
As of this writing, this article is only a couple spots away from the front
page. It's clearly not front page material, though.

Separating a large, complicated task into multiple orthogonal pieces, and
assigning each of these pieces to its own component, has been a fundamental
part of software engineering for many decades.

Separation of concerns is what OO does. Separation of concerns is what UNIX
does. Separation of concerns is what TCP/IP does. Separation of concerns is
why global variables are considered "bad." Separation of concerns is not a new
idea.

This jargon-filled, somewhat poorly worded article is merely repeating a
fundamental principle that should be obvious to anyone who's ever written any
program larger than a couple hundred lines.

What is meant by "[the] client is free to have full coherence of server's
public domain including all its public API, domain objects and schemata"?

"CSDS regards hypermedia an important aspect of REST; it is a semantic web of
interconnected resources. Client will have full coherence of the axes of such
relationships and can effectively use to navigate the semantic web - since it
is part of the public domain. But for it to become the engine of the
application is server dominance." These sentences are a long string of big
words, but I'm not sure that there's actually anything meaningful in them.

Reading this article makes me really wish I had enough karma to downvote.

~~~
aliostad
I am really happy if you think all of this is common sense. In fact a lot of
software best practices are common sense but they do not necessarily
consistent with each other. Even in life, "Always help others" and "Set your
goals and run for them" are common sense but they will make a different person
out of you. There comes a time when you are at a fork and need to make a
decision and then it is down to which one is really what you believe in.

Decision to separate domains of client and server is a big one and has its
implications. CSDS is common sense as is HATEOAS but they are not consistent.
ROCA is also common sense but does not agree with CSDS.

------
PaulHoule
mediocre systems are encapsulated; great systems are codesigned.

~~~
secoif
Co-design is unrelated to encapsulation.

~~~
PaulHoule
There's encapsulation as an engineering practice and then encapsulation as a
religion.

This balls-to-the-walls approach to SOA is one of the shortest and straightest
roads to software development hell. I've seen appaling amounts of money
disappear in failing projects this way. (Ever wonder what happened at Colours?
I used to, until I found out...)

In this wonderland of things being decoupled you find pretty quickly that a
lot of functionality gets duplicated in multiple layers, and whenever that
functionality is at all subtle, you'll find that every implementation is wrong
with different bugs.

A while back I worked with some guy who was into REST and HATEOS and PhD
thesises about as valid as Carlos Castenada's and the result was his team
spent a year and a half building an app that took 20,000 REST calls and 40
minutes to start. In a week of whole-system thinking I was able to get that
down to one POX call and 20 seconds.

He never forgave me.

If you're in one of those organizations that uses scrum as a substitute for
project management, failure is even more assured with SOA. Because then, when
a whole-system problem needs to be solved, everything has to be synchronized
against the phony deadlines imposed by the process so something that could be
done in 6 days ends up taking 6 weeks.

SOA gives people the illusion they're managing complexity so now they can
throw a 20 person team at a job a 4 person team could do. The 20 person team
might get the job done 10% more quickly than the 4 person team, but it's five
times as productive at creating bugs. The 4 person team is more "agile"
because it spends resources on satisfying business needs rather than creating
levels of encapsulation just to have encaspulation, then discovering at the
last minute they put walls in the wrong places and need to take out the
Sawzall (if they don't hand out the pink slips)

The ultimate way to fight complexity is to fight it directly, that is, don't
create it. Every artifact you create is like a puppy you'll need to take care
of. Every address space you cross is another thing that can screw up, so don't
do it because "it's the thing to do", do it because there is a real gain that
overcomes the very real cost.

~~~
DenisM
This is an astute observation, and I think it could benefit from more
examples:

On abstraction layers: ZFS was able to achieve something very novel by cutting
across all abstraction layers which accumulated in storage management over the
decades. I think there is still a lot of work to be done in this direction. I
also think the progress here has to go through the cycles - first we pile on
abstraction layers in our struggle to wrap our minds around the problem area,
then once the problem area is understood we cut through abstract on layers and
create an integrated design (co-design in your terms), and then the cycle
starts a new. Breaking up the problem into abstraction layers is akin to a
child learning to write - at first he has to do it letter by letter, but as
proficiency is gained, the letters blend into words, and words into sentences.
Beyond spelling, learning to compose a good text follows a similar pattern.

On separations of concerns between client and server: resilience of data is
given by the article author as a server concern, and I think that's one great
example where separation is actually harmful. I have recently designed a
system where a server and a client (a mobile device) would cooperate in
preserving data, achieving much greater resiliency than a server alone could
achieve without expensive investments on the server side. In other words,
separated design is more expensive.

~~~
aliostad
Server cannot rely on client for storing its own domain's state - while client
can store user-related state for improving performance, usability.

For example, twitter cannot rely on a client to store the tweets while the
client could cache the recent tweets for improving user experience.

Again, for an app playing music, keeping bookmark of the last song played can
be fully stored on the client. Yet if it is needed to sync this bookmark
across multiple devices (similar to kindle) it becomes a server concern.

~~~
DenisM
Server most certainly _can_ rely on client to store a redundant copy of the
data, as there are ways to ensure the data authenticity. Should the server
fail and get restored from an hour-old backup, the last hour worth of changes
can be fetched from the client, after data integrity verification. Thus the
server could get away with hourly backup instead of every-five-second, or
full-blown database mirroring.

------
ivix
Surely this is the only sane way to design a REST API? Of course taken to
extremes, things can get silly.

As I see it, the point of encapsulation is that you don't know what your
system might be asked to do next. Keeping things reasonably generic allows you
to respond without a major redesign being required.

------
hizanberg
Keeping the client and server separate is a new thing? Isn't that what most of
the world is doing already?

Since the purpose of a service is to provide a service, why would you be
limiting it to specific clients in the first place?

