Update: This was going to be part of a series, but SitePen beat me to the punch with this incredibly exhaustive article, AMD: The Definitive Source. The title is completely accurate.
When it comes to developing scalable web apps (or apps of any sort really) it’s best to keep your code modular. Cowboy code won’t fly when your sweet porn app is getting nailed by a quarter million users in the time it takes to make a sandwich. Right. So, just to be clear I’m not talking about a specific architecture or methodology, I’m talking about approaching your code in a way that works for sites with large codebases and high traffic. IMHO this approach works for and should be used by small apps too. Just sayin.
Why modular architecture
For the love of all that is good, lets get to the point. There are at least five reasons to write modular code (in no particular order):
- Modules can be used in multiple projects without modification
- Can be updated or replaced without affecting the whole
- It’s simpler and easier to develop discrete functionality
- The more it’s used the better it’s tested (no wheel-inventing going on here)
- If the client (AKA, web browser) doesn’t need it, it doesn’t need to be loaded
Let’s get practical.
When said Pointy-Haired Boss decides that he hates the old contact form because “it’s not flashy enough” and wants to replace it with “something more social” or “something that slides out from the side like that one site” you’re good. Gut the old module (probably a bad idea) or create a new one. Either way, the module’s scope is limited so it’s not going to break the rest of the app.
Here’s a rhetorical question. What would you rather work on: a contact form whose functionality is randomly spread across 823 lines of code interspersed with navigation stuff, slidy thingies, some AJAX shit, and a handful of random global functions, or 42 lines of contact form specific code located in a single file called contact_form.js? [5. Thank you very much, smart-ass. Now go read that Cowboy code link in the intro.] Projects big and small can benefit from this type of structure.
The first time you re-use your super-slidy contact form in a different project you will realize it has about a thousand shortcomings. It needs to be easily skinned, “ohmigod it has to slide from the right!”, and whatnot. So you fix it, update all instances, fix bugs, test, reuse. A year later you’ve got a really solid, semi-slidy social contact thingy that 9 other people on GitHub also use. YAY!
Lol. Anyway. There’s no use loading the Super Social Slider Form ME(tm) on every page of your app. Better to include it only where it’s needed. In fact, why not wait to load it until it’s actually needed. Modular code lets you do this kind of thing. When you have the 489kb, 823 line multi-function cluster-fuck version, the client gets it all at once. Kittens die because of this kind of shit. Be nice to your end users by conserving bandwidth, memory, and load times.
Rules To Live By
I’ll save the practicalities of putting together a real module for another post but before I that, there are a few rules to live by.
- Minimize dependencies
- Hold on loosely
- Modules should be loosely coupled. Don’t call a module or its methods directly, instead use observers.
- Do only one thing
- Include all functionality required for the module to work by itself within one module.
Keep these in mind when you’re starting an app and you’re good to go.