How many people out there love RADAR? I’m talking about the so-called RADAR architecture as described by Dave Thomas. The core of the RADAR idea, to me, is simple. Rather than build a large monolithic app, split it up into a REST Application Server and an HTML Presentation Server:
- The Application Server should contain only what is needed for the public RESTful API, i.e. the domain and business logic.
- The Presentation Server should contain the user experience, and as little domain or business logic as possible.
Advantages
Such an architecture would, of course have the benefits that come from REST itself. In addition, you get the advantages from having an application built of small, decoupled components:
- Increased flexibility, in several ways:
- For example, Asbjørn Ulsberg commented that it “gives you the option to switch the presentation application while still using REST in the backend.” Use whatever technology you like for the Presentation Server: Rails, Django, Cocoa, iPhone SDK, Laszlo, and so on.
- Dave Thomas mentioned that you can physically locate the Application Server in various places to suite your needs — perhaps deep in the network cloud, or perhaps on the client’s device (i.e. home computer, phone), or perhaps between (more like a traditional proxy server.)
- The RADAR architecture may well be perfect for M*A*S*H ups
- Increased scalability
- Rather than just having one monolithic application, you have at least two components. So if the Presentation Server is a bottleneck, fire up more of them. One way to handle scalability is with a “divide, measure, and conquer” strategy, and a RADAR architecture helps in this regard.
- Full disclosure: I’m not a scalability guru. So far, the most impressive scaling up I’ve done so far involved a bad diet, too much stress, not enough exercise, and an accumulation of extra mass.
- Rather than just having one monolithic application, you have at least two components. So if the Presentation Server is a bottleneck, fire up more of them. One way to handle scalability is with a “divide, measure, and conquer” strategy, and a RADAR architecture helps in this regard.
- Encourages better design
- This separation is a constraint that will help you build a better REST API. You will have to eat your own dog food, because you will have to consume your own REST Application Server.
Disadvantages
I would suspect that using the RADAR architecture is not a good choice if you are:
- …rapidly prototyping an application
- Please, remember what “prototype” means. Get it out the door quick and see what your users think before you over-architect it.
- …scared of new ideas
- Run away, now, before I introduce the Zombie Architecture.
- …finishing up a Web application
- Release it and get user feedback. Tearing it apart and rebuilding is a risky business. Joel Spotsky, for example, warns against embarking on The Big Rewrite.
Uncertainties
- How will you handle data transfer between the application servers?
- A small amount of data marshaling may not be a problem, but what happens as data transfer needs increase?
- What about the particular case of file uploading? Does an end-user upload to your Presentation Server, which then in turn uploads to your Application Server — that seems wasteful. Perhaps there are more direct ways.
- Might maintaining two different servers slow you down; i.e. reduce your agility?
- Generally speaking, having a clean separation between the two may actually make it clearer to find existing code and to decide where new code should go. This should help agility.
- The agileness of RADAR also will depend on the nature of the change needed:
- Only need to update your Presentation Server? Great, you don’t have to touch the Application Server at all. Not being able to actually touch code makes it a bit harder to introduce a bug or screw up the deployment.
- Don’t worry, if you are really good, you might try to expose a lurking bug that was dormant. Perhaps ironically, doing so will just make the application stronger in the long run.
- Only need to update your Application Server? You don’t need to touch your Presentation Server. (Again, less for your clumsy ass to screw up.)
- If you need to modify both servers, well, then you are more-or-less in the same position you would be in if you weren’t using a RADAR architecture in the first place.
- Only need to update your Presentation Server? Great, you don’t have to touch the Application Server at all. Not being able to actually touch code makes it a bit harder to introduce a bug or screw up the deployment.
Post a Comment