Life above Services v1.0 review
4 views
Skip to first unread message
Peter Laird
Oct 23, 2008, 4:37:20 AM10/23/08
to SOFEA
Hi SOFEArs,
I saw Peter Svensson's Thin Server talk at AjaxWorld, and it matches
where me and my team has been headed the last year. We are taking a
balanced approach (mixing some server side presentation rendering with
some Ajax+REST pieces) with great success.
I read the SOFEA v1.0 document, and wrote up my comments. Hopefully
they are helpful:
Page 8 WS-* and REST are both valid service interfaces
- Both SOAP and REST are considered valid service approaches according
to the document.
- But REST does not mandate XML to be returned! As we all know some
REST APIs only support JSON.
- I find the strict opposition against JSON to be strange given these
facts since that position is based on the idea that the service
interface will be talking XML. Not always true!
Page 12 Thin vs. Rich
- There is a blended approach as well. A sentence or two to recognize
that will make this more objection proof.
- Ex. A portal server handles rendering page layout, Ajax+REST
portlets handle their own flows
- Ex. Type ahead search boxes on standard server gen'd pages
Page 16 HTML as a data transport does not respect data types
- In short, for this section both SOFEA and classic web apps have the
same issues.
- When a SOFEA app issues a GET request with data parameters to a
RESTful API, it suffers from the same shortcomings. No data types, no
hierarchies.
- As for PUT/POSTs with XML bodies, unless SOFEA mandates XML schema
validation on the client (which is not mentioned at all), there is
nothing there to respect data types
- In either architecture, client side validation logic can easily be
added to form fields, but of course that isn't unique to either
architecture
Page 19 Front Controller is an antipattern
- Too strict. There are cases that you will want to blend approaches.
To kill Front Controller completely is a huge mistake.
- Consider an insurance CSR application with 1000 "screens":
200 for customer profile
100 for Personal info
100 for Billing
300 for auto
100 common
50 for cars
100 for trucks
50 for motorcycles
200 for home
50 common
50 for apartments/condos
50 for townhomes
50 for single family homes
300 for life
100 common
50 for men
100 for women
50 for children
You will want to use server side flow control between the major
sections of the application.
1. Reduces app download size to break it up
2. Different teams of devs likely work on each section, so it helps
componentize UI dev
3. Each section is really a related sub application, but a customer
may want to access multiple sections, and thus share basic profile
state across them.
4. There are business rules that may affect the inter-section
navigation for a customer. Controller logic is needed.
Better off with blended server side controller to manage main
naviagation, and SOFEA for each section
Page 21 Server Push
- Both SOFEA and Thin-Client apps have the same limitations wrt push.
Therefore this page doesn't seem to be relevent to the discussion?
- Also, there workarounds as you note that exist today, and the
standard WebSockets coming in HTML5 makes this page not so compelling.
- Vote to strike this entire page.
Page 22 Client side state
- Cookies are another way to maintain state on the client
Page 23: Wasting time building 50 Java controller frameworks
- To be fair, we have also wasted time building at least 50 RIA
frameworks
I saw Peter Svensson's Thin Server talk at AjaxWorld, and it matches
where me and my team has been headed the last year. We are taking a
balanced approach (mixing some server side presentation rendering with
some Ajax+REST pieces) with great success.
I read the SOFEA v1.0 document, and wrote up my comments. Hopefully
they are helpful:
Page 8 WS-* and REST are both valid service interfaces
- Both SOAP and REST are considered valid service approaches according
to the document.
- But REST does not mandate XML to be returned! As we all know some
REST APIs only support JSON.
- I find the strict opposition against JSON to be strange given these
facts since that position is based on the idea that the service
interface will be talking XML. Not always true!
Page 12 Thin vs. Rich
- There is a blended approach as well. A sentence or two to recognize
that will make this more objection proof.
- Ex. A portal server handles rendering page layout, Ajax+REST
portlets handle their own flows
- Ex. Type ahead search boxes on standard server gen'd pages
Page 16 HTML as a data transport does not respect data types
- In short, for this section both SOFEA and classic web apps have the
same issues.
- When a SOFEA app issues a GET request with data parameters to a
RESTful API, it suffers from the same shortcomings. No data types, no
hierarchies.
- As for PUT/POSTs with XML bodies, unless SOFEA mandates XML schema
validation on the client (which is not mentioned at all), there is
nothing there to respect data types
- In either architecture, client side validation logic can easily be
added to form fields, but of course that isn't unique to either
architecture
Page 19 Front Controller is an antipattern
- Too strict. There are cases that you will want to blend approaches.
To kill Front Controller completely is a huge mistake.
- Consider an insurance CSR application with 1000 "screens":
200 for customer profile
100 for Personal info
100 for Billing
300 for auto
100 common
50 for cars
100 for trucks
50 for motorcycles
200 for home
50 common
50 for apartments/condos
50 for townhomes
50 for single family homes
300 for life
100 common
50 for men
100 for women
50 for children
You will want to use server side flow control between the major
sections of the application.
1. Reduces app download size to break it up
2. Different teams of devs likely work on each section, so it helps
componentize UI dev
3. Each section is really a related sub application, but a customer
may want to access multiple sections, and thus share basic profile
state across them.
4. There are business rules that may affect the inter-section
navigation for a customer. Controller logic is needed.
Better off with blended server side controller to manage main
naviagation, and SOFEA for each section
Page 21 Server Push
- Both SOFEA and Thin-Client apps have the same limitations wrt push.
Therefore this page doesn't seem to be relevent to the discussion?
- Also, there workarounds as you note that exist today, and the
standard WebSockets coming in HTML5 makes this page not so compelling.
- Vote to strike this entire page.
Page 22 Client side state
- Cookies are another way to maintain state on the client
Page 23: Wasting time building 50 Java controller frameworks
- To be fair, we have also wasted time building at least 50 RIA
frameworks
Justin Meyer
Oct 23, 2008, 11:51:58 AM10/23/08
to SOFEA
In the spirit of discussion:
On Oct 23, 3:37 am, Peter Laird <peterjla...@gmail.com> wrote:
> Hi SOFEArs,
>
> I saw Peter Svensson's Thin Server talk at AjaxWorld, and it matches
> where me and my team has been headed the last year. We are taking a
> balanced approach (mixing some server side presentation rendering with
> some Ajax+REST pieces) with great success.
>
> I read the SOFEA v1.0 document, and wrote up my comments. Hopefully
> they are helpful:
>
> Page 8 WS-* and REST are both valid service interfaces
>
> - Both SOAP and REST are considered valid service approaches according
> to the document.
> - But REST does not mandate XML to be returned! As we all know some
> REST APIs only support JSON.
> - I find the strict opposition against JSON to be strange given these
> facts since that position is based on the idea that the service
> interface will be talking XML. Not always true!
Absolutely, JSON is becoming the default communication mechanism for
web applications.
> Page 12 Thin vs. Rich
>
> - There is a blended approach as well. A sentence or two to recognize
> that will make this more objection proof.
> - Ex. A portal server handles rendering page layout, Ajax+REST
> portlets handle their own flows
> - Ex. Type ahead search boxes on standard server gen'd pages
Why would you have the portal server handling the page layout? One of
the big strengths of TSA is that for mashups/portals you just have to
put out an HTML file. Having the server rendering the page structure
breaks this.
I believe Dojo can help break up a project like this in the build
process. You would only load what you need. But, with a project that
big, I agree that splitting it up might be the best / easiest thing to
do.
> 2. Different teams of devs likely work on each section, so it helps
> componentize UI dev
I don't understand how this would make a difference. With the
application we are working on right now, we use real simple history to
break the application up into pages anyway. It is just as easy for
someone in Trucks to work along someone in Children on the client. If
you put that on the server, it gets worse because you are stepping on
the Business/Data layer developers toes.
> 3. Each section is really a related sub application, but a customer
> may want to access multiple sections, and thus share basic profile
> state across them.
Does this imply this can't be done with SOFEA?
> 4. There are business rules that may affect the inter-section
> navigation for a customer. Controller logic is needed.
> Better off with blended server side controller to manage main
> naviagation, and SOFEA for each section
Can you give an example? Typically those navigation rules are there
to protect the data from having an incorrect state. As long as your
services prevent this no matter what, why not put this logic client
side?
The great thing about replacing web 1.0 wizard style interfaces with a
TSA application (and a tool like Real Simple History) is that you can
recreate the wizard style interface, never leave your application in a
partially completed state, and still support the back button and
changing information.
However, I am not sure if this type of navigation applies. Can you
give a more concrete example?
> Page 21 Server Push
>
> - Both SOFEA and Thin-Client apps have the same limitations wrt push.
> Therefore this page doesn't seem to be relevent to the discussion?
> - Also, there workarounds as you note that exist today, and the
> standard WebSockets coming in HTML5 makes this page not so compelling.
> - Vote to strike this entire page.
>
> Page 22 Client side state
>
> - Cookies are another way to maintain state on the client
>
> Page 23: Wasting time building 50 Java controller frameworks
>
> - To be fair, we have also wasted time building at least 50 RIA
> frameworks
We've built a lot of RIA libraries. Frameworks I am not so sure
about.
On Oct 23, 3:37 am, Peter Laird <peterjla...@gmail.com> wrote:
> Hi SOFEArs,
>
> I saw Peter Svensson's Thin Server talk at AjaxWorld, and it matches
> where me and my team has been headed the last year. We are taking a
> balanced approach (mixing some server side presentation rendering with
> some Ajax+REST pieces) with great success.
>
> I read the SOFEA v1.0 document, and wrote up my comments. Hopefully
> they are helpful:
>
> Page 8 WS-* and REST are both valid service interfaces
>
> - Both SOAP and REST are considered valid service approaches according
> to the document.
> - But REST does not mandate XML to be returned! As we all know some
> REST APIs only support JSON.
> - I find the strict opposition against JSON to be strange given these
> facts since that position is based on the idea that the service
> interface will be talking XML. Not always true!
web applications.
> Page 12 Thin vs. Rich
>
> - There is a blended approach as well. A sentence or two to recognize
> that will make this more objection proof.
> - Ex. A portal server handles rendering page layout, Ajax+REST
> portlets handle their own flows
> - Ex. Type ahead search boxes on standard server gen'd pages
the big strengths of TSA is that for mashups/portals you just have to
put out an HTML file. Having the server rendering the page structure
breaks this.
process. You would only load what you need. But, with a project that
big, I agree that splitting it up might be the best / easiest thing to
do.
> 2. Different teams of devs likely work on each section, so it helps
> componentize UI dev
application we are working on right now, we use real simple history to
break the application up into pages anyway. It is just as easy for
someone in Trucks to work along someone in Children on the client. If
you put that on the server, it gets worse because you are stepping on
the Business/Data layer developers toes.
> 3. Each section is really a related sub application, but a customer
> may want to access multiple sections, and thus share basic profile
> state across them.
> 4. There are business rules that may affect the inter-section
> navigation for a customer. Controller logic is needed.
> Better off with blended server side controller to manage main
> naviagation, and SOFEA for each section
to protect the data from having an incorrect state. As long as your
services prevent this no matter what, why not put this logic client
side?
The great thing about replacing web 1.0 wizard style interfaces with a
TSA application (and a tool like Real Simple History) is that you can
recreate the wizard style interface, never leave your application in a
partially completed state, and still support the back button and
changing information.
However, I am not sure if this type of navigation applies. Can you
give a more concrete example?
> Page 21 Server Push
>
> - Both SOFEA and Thin-Client apps have the same limitations wrt push.
> Therefore this page doesn't seem to be relevent to the discussion?
> - Also, there workarounds as you note that exist today, and the
> standard WebSockets coming in HTML5 makes this page not so compelling.
> - Vote to strike this entire page.
>
> Page 22 Client side state
>
> - Cookies are another way to maintain state on the client
>
> Page 23: Wasting time building 50 Java controller frameworks
>
> - To be fair, we have also wasted time building at least 50 RIA
> frameworks
about.
Peter Laird
Oct 23, 2008, 4:59:25 PM10/23/08
to SOFEA
Taking one section at a time since this is a lengthy discussion.
>> Page 12 Thin vs. Rich
>> - There is a blended approach as well. A sentence or two to recognize
>> that will make this more objection proof.
>> - Ex. A portal server handles rendering page layout, Ajax+REST
>> portlets handle their own flows
>> - Ex. Type ahead search boxes on standard server gen'd pages
>Why would you have the portal server handling the page layout? One of
>the big strengths of TSA is that for mashups/portals you just have to
>put out an HTML file. Having the server rendering the page structure
>breaks this.
My point is that this section makes it sounds like all apps can be
categorized in a binary way - thin OR rich. In the real world, there
are many shades of gray in between, like my examples. All I am saying
is add a sentence or two towards the beginning recognizing that there
is a continuum. Otherwise the analysis looks too simplistic (the world
is black OR white).
As an aside, the reason our portal server will do server side page
layout is due to its history. Its over 8 years old, has a large
customer base, and to reimplement from the ground up makes no sense.
Instead, the server can layout out the page, and the custom portlets
our customers build can use SOFEA principles.
>> Page 12 Thin vs. Rich
>> - There is a blended approach as well. A sentence or two to recognize
>> that will make this more objection proof.
>> - Ex. A portal server handles rendering page layout, Ajax+REST
>> portlets handle their own flows
>> - Ex. Type ahead search boxes on standard server gen'd pages
>Why would you have the portal server handling the page layout? One of
>the big strengths of TSA is that for mashups/portals you just have to
>put out an HTML file. Having the server rendering the page structure
>breaks this.
categorized in a binary way - thin OR rich. In the real world, there
are many shades of gray in between, like my examples. All I am saying
is add a sentence or two towards the beginning recognizing that there
is a continuum. Otherwise the analysis looks too simplistic (the world
is black OR white).
As an aside, the reason our portal server will do server side page
layout is due to its history. Its over 8 years old, has a large
customer base, and to reimplement from the ground up makes no sense.
Instead, the server can layout out the page, and the custom portlets
our customers build can use SOFEA principles.
Peter Laird
Oct 23, 2008, 5:06:34 PM10/23/08
to SOFEA
>> Page 19 Front Controller is an antipattern
>> - Too strict. There are cases that you will want to blend approaches.
>> To kill Front Controller completely is a huge mistake.
>> - Too strict. There are cases that you will want to blend approaches.
>> To kill Front Controller completely is a huge mistake.
>> You will want to use server side flow control between the major
>> sections of the application.
>> 1. Reduces app download size to break it up
> I believe Dojo can help break up a project like this in the build
> process. You would only load what you need. But, with a project that
> big, I agree that splitting it up might be the best / easiest thing to
> do.
>> 2. Different teams of devs likely work on each section, so it helps
>> componentize UI dev
> I don't understand how this would make a difference. With the
> application we are working on right now, we use real simple history to
> break the application up into pages anyway. It is just as easy for
> someone in Trucks to work along someone in Children on the client. If
> you put that on the server, it gets worse because you are stepping on
> the Business/Data layer developers toes.
I would like to understand the "real simple history" approach that you
>> sections of the application.
>> 1. Reduces app download size to break it up
> I believe Dojo can help break up a project like this in the build
> process. You would only load what you need. But, with a project that
> big, I agree that splitting it up might be the best / easiest thing to
> do.
>> 2. Different teams of devs likely work on each section, so it helps
>> componentize UI dev
> I don't understand how this would make a difference. With the
> application we are working on right now, we use real simple history to
> break the application up into pages anyway. It is just as easy for
> someone in Trucks to work along someone in Children on the client. If
> you put that on the server, it gets worse because you are stepping on
> the Business/Data layer developers toes.
used. Can you blog about it? It seems to me that a massive application
implemented as a Single Page Application would be difficult to pull
off with a large development team (> 20 developers). But, admittedly,
I haven't been on such a project, so I would like to hear your
experience.
Peter Laird
Oct 23, 2008, 5:13:39 PM10/23/08
to SOFEA
Ah, "real simple history" == Real Simple History (RSH). Got it.
Justin Meyer
Oct 23, 2008, 5:39:16 PM10/23/08
to SOFEA
I'm actually consulting on a project like this right now. It's got 21
developers, though only 5 are doing JavaScript.
It's a JavaScriptMVC application. JavaScriptMVC has RSH and routing
built into it. Like rails, it will automatically route a url like:
myapplication.html#children/show&id=5
To ChildrenController::show(params)
where params.id -> 5
If you use gmail or facebook, you'll notice they do the same type of
thing with the url hash (everything after #).
JavaScriptMVC lets you automatically load code when the url changes.
So anytime anyone goes to a new url, say trucks/*, it will
automatically load a trucks 'engine'.
This allows Trucks and Children to work fairly independent of each
other, at least as independent as a framework like Ruby on Rails.
Much of this has to do with JavaScriptMVC's architecture.
Once I started this project, I've realized that although I've learned
some hard lessons about big single page apps, I've never really talked
with anyone else about it. I've been preparing to start asking
around. I even asked Kris Zyp about it, but he hasn't responded yet
(that's right I'm calling you out KZ :-).
This type of research might be a good side project for this group.
developers, though only 5 are doing JavaScript.
It's a JavaScriptMVC application. JavaScriptMVC has RSH and routing
built into it. Like rails, it will automatically route a url like:
myapplication.html#children/show&id=5
To ChildrenController::show(params)
where params.id -> 5
If you use gmail or facebook, you'll notice they do the same type of
thing with the url hash (everything after #).
JavaScriptMVC lets you automatically load code when the url changes.
So anytime anyone goes to a new url, say trucks/*, it will
automatically load a trucks 'engine'.
This allows Trucks and Children to work fairly independent of each
other, at least as independent as a framework like Ruby on Rails.
Much of this has to do with JavaScriptMVC's architecture.
Once I started this project, I've realized that although I've learned
some hard lessons about big single page apps, I've never really talked
with anyone else about it. I've been preparing to start asking
around. I even asked Kris Zyp about it, but he hasn't responded yet
(that's right I'm calling you out KZ :-).
This type of research might be a good side project for this group.
Peter Laird
Oct 23, 2008, 5:42:14 PM10/23/08
to SOFEA
> 3. Each section is really a related sub application, but a customer
> may want to access multiple sections, and thus share basic profile
> state across them.
Does this imply this can't be done with SOFEA?
> 4. There are business rules that may affect the inter-section
> navigation for a customer. Controller logic is needed.
> Better off with blended server side controller to manage main
> naviagation, and SOFEA for each section
Can you give an example? Typically those navigation rules are there
to protect the data from having an incorrect state. As long as your
services prevent this no matter what, why not put this logic client
side?
The great thing about replacing web 1.0 wizard style interfaces with a
TSA application (and a tool like Real Simple History) is that you can
recreate the wizard style interface, never leave your application in a
partially completed state, and still support the back button and
changing information.
However, I am not sure if this type of navigation applies. Can you
give a more concrete example?
To put this in context, remember that I am just suggesting the
> may want to access multiple sections, and thus share basic profile
> state across them.
Does this imply this can't be done with SOFEA?
> 4. There are business rules that may affect the inter-section
> navigation for a customer. Controller logic is needed.
> Better off with blended server side controller to manage main
> naviagation, and SOFEA for each section
Can you give an example? Typically those navigation rules are there
to protect the data from having an incorrect state. As long as your
services prevent this no matter what, why not put this logic client
side?
The great thing about replacing web 1.0 wizard style interfaces with a
TSA application (and a tool like Real Simple History) is that you can
recreate the wizard style interface, never leave your application in a
partially completed state, and still support the back button and
changing information.
However, I am not sure if this type of navigation applies. Can you
give a more concrete example?
document recognize that there may be use cases for "blended", or that
continuum that has already been mentioned. I am not saying SOFEA is
broken, I am just pointing out that this document might want to back
down in its outright condemnation of server side rendering and/or a
Front Controller. There are use cases where they can be successfully
employed, even together with SOFEA.
Server side rendering: imagine that at all times the user will always
have a left column that includes read only information on the current
state of the user's account. Instead of forcing the client to do a
separate round trip for that data, the server could quite easily drop
that presentation information into the left column on the first page
render.
Controller nav: perhaps when navigating between self contained SPA
html files you need to make a routing decision. Like, if the customer
is from one of 20 states, send them to one version of the SPA. If from
the other 30, send to another. You could do make this nav decision
client side, but a server side controller decision could work just as
well.
Justin Meyer
Oct 23, 2008, 6:24:02 PM10/23/08
to SOFEA
Ah, well I agree that blended could work just as well even better -
depending on the application requirements. And, some discussion on
where those breaking points is valid.
However, I disagree that a presentation should say anything about the
continuum.
Maybe it's because I'm an American, but people typically need to be
hit over the head with something before they consider it. It's a sad
and unfortunate reality.
If Peter gives a tepid description of SOFEA, he might as well not give
it. In my opinion, only by saying that SOFEA will solve not only your
development problems, but world hunger, baldness, and make your wife
look 5 years younger, will you get 'Joe the Developer' to even
consider it. The majority of developers have the inertia of a million
solar mass black hole (I'm allowed to make Astronomy jokes right?).
If you they have a complex application, where there might be a need
for service re-use, and they want to provide some rich features, there
are such overwhelming advantages to SOFEA/TSA, that not worth
discussing the other possibilities.
depending on the application requirements. And, some discussion on
where those breaking points is valid.
However, I disagree that a presentation should say anything about the
continuum.
Maybe it's because I'm an American, but people typically need to be
hit over the head with something before they consider it. It's a sad
and unfortunate reality.
If Peter gives a tepid description of SOFEA, he might as well not give
it. In my opinion, only by saying that SOFEA will solve not only your
development problems, but world hunger, baldness, and make your wife
look 5 years younger, will you get 'Joe the Developer' to even
consider it. The majority of developers have the inertia of a million
solar mass black hole (I'm allowed to make Astronomy jokes right?).
If you they have a complex application, where there might be a need
for service re-use, and they want to provide some rich features, there
are such overwhelming advantages to SOFEA/TSA, that not worth
discussing the other possibilities.
Peter Svensson
Oct 24, 2008, 12:17:05 AM10/24/08
to so...@googlegroups.com
My comments inline. Sorry to come in late to the discussion.
Well, the whole point of TSA and SOFEA is to condemn server-side rendering. Arguing for it goes against the whole idea and makes the document at the same time contradict itself.
But there is one very specific scenario where I consider server-side rendering to be OK (not just in general or when one feel like it), and that is when you need to 'seed' the client with initial data. Server-side templateing/rendering is the only technique for doing so.
Examples of when that could be necessary would be if the client absolutely must start which a large data-set. Embedding the first state of the client datastore inside the page when loaded will avoid an extraneous trip to the server for the data after tha page has been loaded.
However, if the client retreive small amounts of data irregurarly, does not need a big upfront seeding and/or require specific user interaction before it knows what to get, then this is uncessary.
I don't agree here either, since it would be very simple to either calculate the state in the client (if considered safe) or have the client get status at regular intervals or read the state piggybacked on other responses from the server. Either way this is not a scenario where you need to break the TSA model either.
Of course, everything can be created on th server in a classic manner. What I'm trying to argue is that mixing problem domains (client logic on the server) is just as bad as when mixing problem domains in an ordinary program. You end up maintaining two kind of problems inside the same class. A lot of effort has gone into managing that complexity (the current generation of server-based web frameworks), but the problem is not really solvable since the client actually is not there.
That does not mean it is impossible, to the contrary I've had a lot of productivity when using Tapestry, compared to when I tried to hack up my own stuff. So in that respect the server-based web framweorks has been a smashing success.
My (and ours, I hope) point is foremost that using a clean separation of concerns between client and server gives at least as big a boost in prductivity due to simplifying the application and its development, as going from homemade JSP-pages to the current frameworks. TSA and SOFEA are not meant to be academic exercises that could just as well be done the other way around, they're meant to be guidelines on how to lower project churn and complexity.
Cheers,
PS
Well, the whole point of TSA and SOFEA is to condemn server-side rendering. Arguing for it goes against the whole idea and makes the document at the same time contradict itself.
But there is one very specific scenario where I consider server-side rendering to be OK (not just in general or when one feel like it), and that is when you need to 'seed' the client with initial data. Server-side templateing/rendering is the only technique for doing so.
Examples of when that could be necessary would be if the client absolutely must start which a large data-set. Embedding the first state of the client datastore inside the page when loaded will avoid an extraneous trip to the server for the data after tha page has been loaded.
However, if the client retreive small amounts of data irregurarly, does not need a big upfront seeding and/or require specific user interaction before it knows what to get, then this is uncessary.
Server side rendering: imagine that at all times the user will always
have a left column that includes read only information on the current
state of the user's account. Instead of forcing the client to do a
separate round trip for that data, the server could quite easily drop
that presentation information into the left column on the first page
render.
I don't agree here either, since it would be very simple to either calculate the state in the client (if considered safe) or have the client get status at regular intervals or read the state piggybacked on other responses from the server. Either way this is not a scenario where you need to break the TSA model either.
Controller nav: perhaps when navigating between self contained SPA
html files you need to make a routing decision. Like, if the customer
is from one of 20 states, send them to one version of the SPA. If from
the other 30, send to another. You could do make this nav decision
client side, but a server side controller decision could work just as
well.
Of course, everything can be created on th server in a classic manner. What I'm trying to argue is that mixing problem domains (client logic on the server) is just as bad as when mixing problem domains in an ordinary program. You end up maintaining two kind of problems inside the same class. A lot of effort has gone into managing that complexity (the current generation of server-based web frameworks), but the problem is not really solvable since the client actually is not there.
That does not mean it is impossible, to the contrary I've had a lot of productivity when using Tapestry, compared to when I tried to hack up my own stuff. So in that respect the server-based web framweorks has been a smashing success.
My (and ours, I hope) point is foremost that using a clean separation of concerns between client and server gives at least as big a boost in prductivity due to simplifying the application and its development, as going from homemade JSP-pages to the current frameworks. TSA and SOFEA are not meant to be academic exercises that could just as well be done the other way around, they're meant to be guidelines on how to lower project churn and complexity.
Cheers,
PS
Peter Laird
Oct 24, 2008, 12:53:04 PM10/24/08
to SOFEA
Thanks for joining the discussion Peter!
The notion of "blended" architecture seems to have taken over this
thread. I brought it up in the context of a suggestion to soften the
language in the document towards such an approach, and apparently that
is not popular. I can live with that, so let's close out that
discussion on this thread. (though I think the discussion of the
merits of blended should be a thread on its own).
Closing out from further discussion:
- Page 12 Thin vs. Rich
- Page 19 Front Controller is an antipattern
Curious about any more comments on the rest of the review?
- Page 8 WS-* and REST are both valid service interfaces
- Page 16 HTML as a data transport does not respect data types
- Page 21 Server Push
- Minor comments on Page 22 and 23
The notion of "blended" architecture seems to have taken over this
thread. I brought it up in the context of a suggestion to soften the
language in the document towards such an approach, and apparently that
is not popular. I can live with that, so let's close out that
discussion on this thread. (though I think the discussion of the
merits of blended should be a thread on its own).
Closing out from further discussion:
- Page 12 Thin vs. Rich
- Page 19 Front Controller is an antipattern
Curious about any more comments on the rest of the review?
- Page 8 WS-* and REST are both valid service interfaces
- Page 16 HTML as a data transport does not respect data types
- Page 21 Server Push
- Minor comments on Page 22 and 23
Reply all
Reply to author
Forward
0 new messages