AESTHETIC IO

Become a World Class Developer

Become a World Class Developer by Learning How to
Focus On The Things That Really Matter.

www.aestheticio.com

Web App Architecture 101

AESTHETIC IO

Copyright 2014 Stephen Young

All Rights Reserved
Feel free to email, tweet, blog, and pass this ebook around
the web ... but please dont alter any of its contents when you
do. Thanks!
www.aestheticio.com

www.aestheticio.com

Web App Architecture 101

AESTHETIC IO

Contents
Contents

How you can get ahead by focusing on principles and not technologies5
Why should you focus on principles and not technologies?

Some practical tips.

Conclusion

15 Questions developers must ask themselves every day.

Is there a pattern here?

How can I make this simpler?

Why does it work like that?

Has somebody done this before?

Who said it first?

Do I love what Im doing?

10

Where else could I use this?

11

What did I fail at today?

11

How can we make this possible?

11

Who can I learn from?

12

Am I learning the right things?

12

How can I make this more transparent?

13

What is the return on effort?

13

Am I solving the right problem?

13

Does anybody care?

14

Start today

14

12 Attributes of a good web architecture

15

Developer productivity

15

Elegance

15

Usability

16

Security

16

Reliability

16

Performance

17

Scalability

17

Testability

17

Interoperability

18

Transparency and troubleshooting.

18

Community and Product Growth

www.aestheticio.com

18

Web App Architecture 101

Deployability

AESTHETIC IO
19

Why your code is so hard to understand

20

Problem #1, overly complex mental models.

20

Problem #2, poor translation of semantic models into code.

21

Class structure and names.

21

Single responsibility principle (SRP).

22

Appropriate comments.

22

Problem #3, not enough chunking.

22

Problem #4, obscured usage.

23

Problem #5, no clear path between the different models

23

Problem #6, inventing algorithms

24

Conclusion.

24

Learn how to build damn good web apps

www.aestheticio.com

25

Web App Architecture 101

AESTHETIC IO

How you can get ahead by

focusing on principles and not
technologies
Are you running to stand still?
Well, in our country, said Alice, still panting a little, youd generally get to
somewhere else if you run very fast for a long time, as weve been doing.
A slow sort of country! said the Queen. Now, here, you see, it takes all the
running you can do, to keep in the same place. If you want to get somewhere
else, you must run at least twice as fast as that!
- Lewis Carroll from Alice in Wonderland.
As web app developers you are accustomed to the process of constantly having to
learn and adapt to an ever changing technology landscape. It is obvious that to
keep your skills relevant and competitive you need to always be up to date with
the latest technologies.

Why should you focus on principles and not

technologies?
If all you are doing is learning each new technology as it comes out what you are
doing is running as fast as you can just to stand still. You need to run faster than
that!
So how do you do this?
By looking for the underlying principles and driving forces behind new
technologies. Technologies are coming out at an ever increasing pace. If you pay
attention you will start to notice the underlying trends that drive this relentless
innovation.
What do DCOM, CORBA and Webservices have in common? One similarity is that
they are all RPC mechanisms. Each one progressively tries to be more and more
www.aestheticio.com

Web App Architecture 101

AESTHETIC IO

platform agnostic. They are very different beasts yet they share a few core
characteristics.
Since they share characteristics you can safely assume that they will also have
some of the same problems in your web app. How do you handle versioning of the
RPC call? If you have a large distributed team, how do you limit uncontrolled
growth of your remote APIs?
The more you focus on the underlying similarities the larger head start you will
have the next time something new comes along.
By all means learn those new web app technologies but dont just learn the new
API, try understand what makes this new solution unique (if anything). Try see
how this new solution is just a re-incarnation of a previous one. Over time as you
do this you will gain perspective.
Principles like information hiding, decoupling, simplicity and the like are universal
and change very slowly if at all. Technologies like Microsoft Application Blocks,
Ruby on Rails, the latest IoC container change at a break neck pace.

Some practical tips.

Here are a few tips to keep in mind as you learn a new technology.
Try to answer these questions about each new technology you learn:

Which older technologies was this inspired by?

Which problems is it trying to solve?
Which other new technologies are also solving the same problems?
How are all these technologies similar?
How do they differ?

Then try to complete this sentence in as few words as possible:

Just like <list of old technologies> <new technology> is <main purpose they all have in
common>. Unlike previous attempts <new technology> is <what it is trying to do
differently> by <how its doing it differently>.

www.aestheticio.com

Web App Architecture 101

AESTHETIC IO

Conclusion
Any good web app developer eventually starts seeing these trends just based on
depth of experience. You can get a head start by actively paying attention.
Are you happy with running to stand still or do you want to get ahead of the pack?
The choice is yours.

www.aestheticio.com

Web App Architecture 101

AESTHETIC IO

15 Questions developers must ask

themselves every day.
So you want to be a great developer?
Well then its time to put down that Learn Super Duper Language v8.3 in 24 hours
book. Instead, make it a habit to ask yourself these 10 questions every day.

Is there a pattern here?

Looking for patterns in what works and what doesnt work leads to discovering the
underlying principles that drive seemingly unrelated concepts and behaviours. To
get a deeper understanding of the work that you do make it a habit of asking
yourself Is there a pattern here?.
This applies to more than just your code. Is there a pattern in the types of changes
requested by business? Is there a pattern in the way technologies evolve? Are you
seeing the same types of bugs popping up again and again?
To understand is to perceive patterns
- Isaiah Berlin

How can I make this simpler?

Often as developers we want to produce complex and scalable solutions. Making
something tremendously complex makes you feel like the master of your universe.
The problem is that you will never be able to predict how your product and
business is going to change in the future.
Architecture and coding is much more like gardening than architecture. You need
to be able to adapt to an ever changing environment. The more complex your
solution the more difficult this becomes.
Simplicity is the ultimate sophistication.
- Leonardo da Vinci
www.aestheticio.com

Web App Architecture 101

AESTHETIC IO

Why does it work like that?

Knowing that something works and knowing why it works that way are two very
different things. If you know why something behaves the way it does you are able
to make significantly better decisions.
The difference between a great coder and somebody who knows a programming
language is the depth of understanding that comes from understanding why.
The same principle applies when fixing an issue. Just restart the service. Have
you tried rebooting it? We have all said something along those lines when a
problem pops up. Every time you say something like that you lose a golden
opportunity to learn.
Understanding why something broke allows you to fix the root cause and eliminate
this class of issues permanently. At the very least you wont make the same
mistake again.

Has somebody done this before?

Whenever you find yourself inventing a complex algorithm you are probably on the
wrong track. Unless you are busy researching a PHD thesis chances are extremely
good that somebody else has already solved this problem.
Need to write an algorithm to add a label to the item closest to a users mouse?
Have a look at Voronoi Tesselations. Want to find the shortest path for a delivery
truck? Look at Dijkstra. Want to find tags similar to the one the user just entered,
how about figuring out its Levenschtein distance.
Those are just a few examples but trust me, they are everywhere.
If I have seen further it is by standing on the shoulders of Giants.
- Isaac Newton

Who said it first?

www.aestheticio.com

Web App Architecture 101

10

AESTHETIC IO

So you think you know REST right?

Have you read Roy Fieldings original paper describing REST and do you
understand its intended purpose? That blog post by that guy who has 5 minutes
more experience than you using the REST API generation wizard in Super cool IDE
v7 doesnt count.
Do yourself a favour and always try read the original source of a concept or theory.
Then by all means go read the latest developments by industry thought leaders
but if you dont know where they started how can you follow where they are going?

Do I love what Im doing?

Lets face it programming is hard.
Besides being hard programming is constantly evolving. The state of the art
framework from 2 years ago is a clunky dinosaur by todays standards. To stay at
the top of your game you will need to commit to a lifelong process of learning and
research.
If you dont love what you are doing you dont have a hope in hell of keeping up
with the guys who do. So find out what kind of coding gets you fired up. Dont
decide to become a security specialist because there is a gap in the market or
because it pays well, dont become a UX expert just because an article just came
out in WIRED saying that UX is the hottest job in tech.
Ill say it again, do what you love.
Do what you love and the necessary resources will follow.
- Peter McWilliams

www.aestheticio.com

Web App Architecture 101

11

AESTHETIC IO

Where else could I use this?

One of the biggest limits I see developers placing on themselves is a failure of
imagination.
If we learn something in a specific context or see a technique used to solve a
specific problem we assume thats the only place it applies. This is almost always
wrong. Every time you learn something new ask yourself: Where else could I use
this?.
Found great new positioning methods to place nodes on a graph, how about
applying that same technique to find interesting data points in a dataset that has
2 dimensions? Found a cool way to send data over websockets from the client to
the server? How would this apply in making a scalable set of backend services?
Sometimes you will be wrong, but sometimes you will be right.
Logic will get you from A to Z; imagination will get you everywhere.
- Albert Einstein

What did I fail at today?

One of the easiest ways to increase innovation is to lower the cost of failure.
The game developing company Valve has embraced this like few others. The same
applies to your progression as a developer, if you are afraid to fail you will never
make those big breakthroughs.
Be brave, try something, fail, learn and try again.
Do not fear mistakes. You will know failure. Continue to reach out.
- Benjamin Franklin

How can we make this possible?

In the world we live in there really is very little that is impossible (with a few
exceptions).
www.aestheticio.com

Web App Architecture 101

12

AESTHETIC IO

Start from the assumption that whatever you want to do is possible and then work
your way back. You might find that what you wanted to do is impractical for the
time being but with the pace of change in todays world, it might become practical
sooner than you think.
It always seems impossible until its done.
- Nelson Mandela

Who can I learn from?

You should never work anywhere where you are the smartest person in the room.
Pick jobs and companies where you can work with people who inspire you and
challenge you to be better. It doesnt have to be coding related, there is a world
outside your text editor and the command line. Learn things from other fields and
find ways to apply it in your job.
Being competent isnt good enough anymore.

Am I learning the right things?

I assume you are already actively learning.
You wouldnt be reading this post if you didnt want to learn. Are you learning the
right things though?
People often tell me: Im learning a new language and they invariably mention
another language just like the one they already know. If you have a toolbox full of
hammers rather invest in a screwdriver.
If you know OO, learn a functional language. I recommend Haskell since there is no
way to cheat, be warned, your brain might melt a little.
If you have those 2 under the belt check out a logical language like Prolog. Make
sure you know a dynamic language like Ruby. And if you get a chance check out
APL. Its beautiful.
www.aestheticio.com

Web App Architecture 101

13

AESTHETIC IO

How can I make this more transparent?

The hardest part of fixing a problem is finding it.
Do everything in your power to make your solutions transparent. Write lavish logs,
throw exceptional exceptions, make your code clean and sparkly.
Every time you struggle to find a problem make sure the next guy can find it with
less effort.

What is the return on effort?

Everything comes at a cost. Not writing that unit test buys you a few minutes right
now but at what cost later on? Taking a week to research existing algorithms
might save you 3 months in development time by the end of the project.
If it takes you 20 minutes to do a deployment and you do 10 deployments a week,
how long until taking those 3 hours to automate it is paid back?
That plugin framework that might possibly save you 2 days one day. Does it make
the things you do everyday take 5 minutes longer? How long until those 5 minutes
add up to more than those mythical 2 days?
This is a marathon, not a sprint.

Am I solving the right problem?

Writing a script to periodically restart a service to improve stability is awesome.
Whats even more awesome is fixing the memory leaks that make the service
crash.
Created a marvellous multi threaded app to generate 20 concurrent crystal
reports? Nice! Why not investigate a switch to XSL-FO so each report doesnt take
3 years to generate.
www.aestheticio.com

Web App Architecture 101

14

AESTHETIC IO

Question everything.
If you get a set of requirements that dont solve the right problem. Speak up! You
are more than a code typist, you are a problem solver.

Does anybody care?

This is probably the most important one of the lot.
If what you are building doesnt make somebodies life better, gives them more
time, saves them money.
Why are you doing it?

Start today
I know this list is long and it might seem like a lot to take in.
You dont have to do it all at once though. Try this; find somebody you work with
who is also on a mission to be the best they can be. Pick one question per week
and commit to asking each other that question at least once a day. Think about
your answers, be honest, be better.
Good luck!

www.aestheticio.com

Web App Architecture 101

15

AESTHETIC IO

12 Attributes of a good web

architecture
So you have a working web app but is the architecture any good?
While every solution is unique there are a few attributes that any good architecture
should display. If you have been asking yourself the questions I listed previously
you should have a solution that shows most of these attributes.
Have a look at your last web app and see how it scores on the list of 10 quality
attributes below.

Developer productivity
Since smart people are the most precious resource you have any framework or
architecture we adopt needs to help optimize developer productivity time.
Attributes:
Simplicity
Concise but not obtuse
Standardized way of doing things
Great supporting tools
Short feedback loops
Expressiveness
Quality 3rd party packages?

Elegance
The elegance of the solution speaks to how well the solution fits the problem
space and how coherent the solution is.
Attributes
Consistent way of solving a problem.
The most common tasks are the easiest to do.
Clear guidance on how to make architectural choices.
Easily extendable in the appropriate places.
As simple as possible but no simpler.
www.aestheticio.com

Web App Architecture 101

16

AESTHETIC IO

Strong cohesion / low coupling

The problem space forms a large percentage of the frameworks solution space

Usability
Usability is vitally important for a number of reasons. It improves trust, customer
satisfaction and reduces support costs. Any technology you use should allow you
to build a world class user experience.
Attributes
No vendor specific technologies
Support the latest standards
Must provide fast response times in the UI
Allow for use of graphic and charting capabilities
Allow animation where appropriate
Must support A/B testing
Must support analytics

Security
Security is the capability of a system to reduce the chance of malicious or
accidental actions outside of the designed usage of the system, and prevent
disclosure or loss of information.
Attributes
Passes 3rd party penetration tests
Uses security standards wherever possible
Follows security best practices.

Reliability
Reliability is the ability of a system to continue operating in the expected way over
time. Reliability is measured as the probability that a system will not fail and that
it will perform its intended function for a specified time interval
Attributes
It doesnt crash
Autonomic when it crashes it heals itself
No single point of failure
www.aestheticio.com

Web App Architecture 101

17

AESTHETIC IO

Performance
Performance is an indication of the responsiveness of a system to execute
specific actions in a given time interval. It can be measured in terms of latency or
throughput. Latency is the time taken to respond to any event. Throughput is the
number of events that take place in a given amount of time.
Attributes
Support an appropriate level of performance.
Low latency to the UI (< 250 ms for 90% of requests,, <2s for all requests) or
provide mechanisms to compensate (messaging, caching, etc)

Scalability
Scalability is the ability of a system to either handle increases in load without
impact on the performance of the system, or the ability to be readily enlarged.
Attributes
We prefer scaling out to scaling up.
Easy to add more processing nodes.
Easy to load balance new nodes.
Each node should be low overhead.
Licensing should not prevent scaling.

Testability
Testability is a measure of how well a system or components allow you to create
test criteria and execute tests to determine if the criteria are met.
Attributes
Provide mechanisms to mock data.
Trigger back end processes via scripting.
Batch processes should be fast when using small data sets.
Easy to create known data.
Ability to automate UI testing.

www.aestheticio.com

Web App Architecture 101

18

AESTHETIC IO

Interoperability
Do you play well with others? Communication protocols, interfaces, and data
formats are the key considerations for interoperability. Standardisation is also an
important aspect to be considered when designing an interoperable system.
Attributes
Use open standards where available.
Publish standards where not available.
Provides you with many options when selecting 3rd party systems

Transparency and troubleshooting.

When something goes wrong how easy is it to track down the error and re-produce
it?
Attributes
All errors and important events are logged in a meaningful way
Easily comprehensible stack traces
All data needed to re-produce an error is included in the log
Debug logs can be turned on and off
It should be easy to trace an error all the way through the application.

Community and Product Growth

There should be a strong community behind the product you are using. Having
other people who have already solved the problems you are facing is a major
factor in how easy a product or framework is to live with.
Attributes
Many plugins and open source projects related to the framework
Active repo on github if its open source
Lots of questions and answers on stack overflow.
A Google trends graph that is going up and to the right.
Many books, blogs and tutorials.

www.aestheticio.com

Web App Architecture 101

19

AESTHETIC IO

Deployability
Deployment and propagation through different environments is a huge cost. A
product that is difficult to deploy requires longer release cycles and makes it
harder to respond to change or fix bugs.
Attributes
Automated scriptable deployments
Automated tests are easy to write.
Fast build times.
File based configuration or easily scriptable configuration.
Small physical size.
Licensing should not prevent multiple environments.
Easy rollback
Next time you evaluate a web stack or your app design go through this list and try
see if you can tweak your design to tick more of the boxes outlined above.

www.aestheticio.com

Web App Architecture 101

20

AESTHETIC IO

Why your code is so hard to

understand
"What the hell was I thinking?!?"
It's 1:30AM and I am staring at a piece of code I wrote no more than a month ago.
At the time it seemed like a work of art. It all made sense. It was elegant and
simple and amazing. Not anymore. I have a deadline tomorrow and discovered a
bug a few hours ago. What seemed simple and logical at the time just doesn't
make sense anymore. Surely if I wrote the code I should be smart enough to
understand it?
After one too many experiences like this I started thinking seriously about why my
code makes perfect sense while I am writing it but looks like gibberish when I go
back to it a few weeks or months later.

Problem #1, overly complex mental models.

The first step in understanding why your code is hard to read when you come back
to it after a break is understanding how we mentally model problems. Almost all
the code you write is trying to solve a real world problem. Before you can write any
code you need to understand the problem you are trying to solve. This is often the
hardest step in programming.
In order to solve any real world problem we first need to form a mental model of
that problem. Think of this as the intent of your program. Next you need to form a
model of a solution that will achieve your programs' intent. Lets call this the
semantic model. Never confuse the intent of your program with your solution to
that intent. We tend to think primarily in terms of solutions, and often bypass the
formation of a model of intent.
Your next step is to form the simplest semantic model possible. This is the second
place things can go wrong. If you don't take the time to really understand the
problem you are trying to solve you tend to stumble onto a model as you code. If
on the other hand you really think about what you are trying to do you can often
come up with a much simpler model that is sufficient to achieve your original
intent.
www.aestheticio.com

Web App Architecture 101

21

AESTHETIC IO

Eliminating as much of this accidental complexity as possible is crucial if you

want easy to maintain, simple code. The problems we are trying to solve are
complex enough. Don't add to it if you don't have to.

Problem #2, poor translation of semantic models into

code.
Once you have formed the best semantic model you can it's time to translate that
into code. We'll call this the syntactic model. You are trying to translate the
meaning of your semantic model into syntax that a computer can understand.
If you have an amazing semantic model but then mess it up in the translation to
code you are going to have a hard time when you need to come back to change
your code at a later stage. When you have the semantic model fresh in your mind
it's easy to map your code onto it. It's not hard to remember that a variable named
"x" is actually the date a record was created and "y" the date it was deleted. When
you come back 3 months later you don't have this semantic model in your head so
now those same variable names make no sense.
Your task in translating a semantic model into syntax is to try and leave as many
clues as possible that will allow you to rebuild the semantic model when you come
back at a later time.
So how do you do this?

Class structure and names.

If you are using an OO language try and keep your class structure and names as
close to your semantic model as possible. Domain Driven Design is a movement
that places extreme importance on this practice. Even if you don't buy into the full
DDD approach you should think very carefully about class structure and names.
Each class is a clue you leave for yourself and others that will help you re-build
your mental model when you return later.
Variable, parameter and method names.
Try avoid generic variable and method names. Don't call a method "Process" when
"PaySalesCommision" makes more sense. Don't call a variable "x" when it should
www.aestheticio.com

Web App Architecture 101

22

AESTHETIC IO

be "currentContract". Don't have a parameter named "input" when

"outstandingInvoices" is better.

Single responsibility principle (SRP).

The SRP is one of the core Object Oriented Design Principles and ties in with good
class and variable names. It states that any class or method should do one thing
and one thing only. If you want to give classes and methods meaningful names
they need to have a single well defined purpose. If a single class reads and writes
from your database, calculates sales tax, notifies clients of a sale and generates
an invoice you aren't going to have much luck giving it a good name. I often end up
refactoring a class because I struggle to give it a short enough name that
describes everything it does.

Appropriate comments.
If you need to do something for a reason that isn't made clear in your code have
pity on your future self and leave a note describing why you had to do it.
Comments tend to get stale quickly so I prefer having the code as self describing
as possible and the comments are there to say why you had to do something, not
how it was done.

Problem #3, not enough chunking.

Chunking in psychology is defined as the grouping of information as a single
entity. So how does this apply to programming? As you gain experience as a
developer you start to see repeating patterns that crop up over and over again in
your solutions. The highly influential Design Patterns: Elements of Reusable
Object-Oriented Software was the first book to list and explain some of these
patterns. Chunking doesn't only apply to design patterns and OO though. In
functional programming (FP) there are a number of well known standard functions
that serve the same purpose. Algorithms are another form of chunking (more on
this later).
When you use chunking (design patterns, algorithms and standard functions)
appropriately it allows you to stop thinking about how the code you write does
something and instead think about what it does. This reduces the distance
between your syntactic model (your code) and the semantic model (the model in
www.aestheticio.com

Web App Architecture 101

23

AESTHETIC IO

your head). The shorter this distance the easier it is to re-build your mental model
when you return to your code at a later stage.
If you are interested in learning more about the functions used in FP have a look at
my article on functional programming for web developers.

Problem #4, obscured usage.

Up to now we have mainly spoken about how to structure your classes, methods
and variable names. Another important part of your mental model is
understanding how these methods are supposed to be used. Once again this is
quite clear when you initially form your mental model. When you come back later
it's often quite difficult to reconstruct all the intended uses of your classes and
methods. Usually this is because different usages are scattered throughout the
rest of your program. Sometimes even across many different projects.
This is where I find test cases to be very useful. Besides the obvious benefits
associated with knowing if a change broke your code, tests provide a full set of
example use cases for your code. Instead of having to trawl through a hundred
files, looking for references you can get a full picture just by looking at your tests.
Bear in mind that in order for this to be useful you need to have a complete set of
test cases. If your tests only cover some of your intended uses you are going to be
in trouble later on if you assume the tests are complete.

Problem #5, no clear path between the different models

Often your code is technically very good, and extremely elegant, but there is a very
unnatural jump from program intent to semantic model to code. It's important to
consider the transparency of the stack of models you select. The journey from the
program intent to semantic model to code needs to be as smooth as possible. You
should be able to see all the way through each model to the problem. It may at
times be better to choose a particular class structure or algorithm not for its
elegance in isolation, but for its ability to connect the various models and leave a
natural path towards reconstructing intent. As you go from abstract program
intent to concrete code the choices you make should be driven by the clarity with
which you're able to represent the more abstract model below it.

www.aestheticio.com

Web App Architecture 101

24

AESTHETIC IO

Problem #6, inventing algorithms

Often we as programmers think we are inventing algorithms to solve our problems.
This is hardly ever the case. In almost all cases there are existing algorithms that
can be put together to solve your problem. Algorithms like Dijkstra's algorithm,
levenshtein distance, voronoi tessellations etc. Programming for the most part
consists of choosing existing algorithms in the right combination to solve your
problem. If you are inventing new algorithms you either don't know the right
algorithm or are working on your PhD thesis.

Conclusion.
In the end it boils down to this: as a programmer your goal is to construct the
simplest possible semantic model that would solve your problem. Translate that
semantic model as closely as possible into a syntactic model (code) and provide
as many clues as possible so that whomever looks at your code after you can recreate the same semantic model you originally had in mind.
Imagine you are leaving breadcrumbs behind you as you walk through the brightly
lit forest of your code. Trust me, when you need to find your way back later on, that
forest is going to seem dark and misty and foreboding.
It sounds simple but in reality it is very difficult to do well.

www.aestheticio.com

Web App Architecture 101

25

AESTHETIC IO

Learn how to build damn good

web apps
Building world class web apps is hard.
Trust me I know, I have been building web apps for the last 15 years. There is a
massive amount to know and a new technology comes out almost on a daily
basis. This site isn't for people looking for a silver bullet. It's for those of you who
love the web and are willing to put in the time and effort required to build your skill
set. In the free member library I try and point you in the right direction.

Click Here to find out more

With the eBooks in the library I help you focus on the right things so you don't
waste your time.
You will learn:
How to be better at learning and get a head start.
How focusing on principles gives you an unfair advantage.
How to build skills outside your current role and become more marketable.
Click the Free Registration button below, choose your username and password,
and sign up for our free membership library. You will get instant access to ebooks
about every facet of building damn good web apps.

Free Registration

www.aestheticio.com