The First, Possibly The Last
This whole thing could send me over the Cliffs of Insanity. It's ambitious, geeky, overwhelming probably stupid and with a light sprinkling of hubris. In other words: * It should be simple.*
I'm going to build a mirror Tekpub site written with all the buzzwords/new stuff I can think of. And I'm going to blog it, and I'm going to drag Derick down with me. The goodies, specifically, are:
- Some kind of document DB
- Backbone AND EmberJS (no, I won't be looking at KnockoutJS. More below...)
- HTML5 with Responsive Design
- Some type of CSS meta language
- Mocha/Jasmine for testing
See? Told you I was chasing buzzwords.I don't know what will come of this site - maybe it will serve as a nice sample site for people to look at and throw things at. Maybe it will serve as a nice, big shark for me to jump. Or maybe, just maybe, if it does the things I'm hoping it will do - maybe I'll roll it live. Who knows.
To be perfectly honest I like Tekpub right where it is. It looks nice, works reasonably well and I'm able to create content. So what the hell is wrong with me that I would do this? More on that below...
Note: I know many people will call me names at this point and I probably would deserve most of that. Yes, I can be a Magpie, yes I like new technologies, yes I like to look forward in favor of "getting work done". I'm that guy. I always have been, always will be. You need guys like me to do this kind of recon for you (if you're grumbling at me right now)...
So Invite you to come along with me and armchair-code this app. And hopefully along the way we'll learn something together...
Have You Looked At...
Which brings me to why I'm doing this in the first place. Here it goes:
- I love learning. I like learning out in public even more. I like collaboratively learning in public the mostest.
- I'm rolling together a NodeJS production and what I do here will absolutely be a part of it.
- Derick and I will be recording our progress as we go and I'll put it out on Tekpub. He codes at night while
I sleep, I code while he's having dinner with his family - we'll talk in the mornings and evaluate what we've done, the problems we've faced, the answers we've come up with.
- I don't want to lock this all away - so I'm going to blog it (and so is Derick). If you want to know some gory details and see the play by play - it'll be up on Tekpub
- Sometimes knowing if something "has legs" means seeing if it can solve your problems. I'll do that here - and we'll all learn.
I know Backbone a little bitand during that time I also evaluated Knockout. Knockout is quite functional, but it's not what I'm looking for. I could also stick with Rails and PostGres for that matter - but then what's the point of this exercise? I want to dig in to this stuff and I want to know what's going on so I can intelligently answer questions.
Anyway - the first thing I need to decide is where the data is going to live. From there I can decide my data access and then how I might want my model to take shape. I'll get to that in just a minute - let's take a second and decide WTF it is we're doing to begin with.
I want Alt.Tekpub to have a robust API that any client app can talk to: iOS, Android, JS, Silverlight... whatever. The API needs to expose all the functionality of Tekpub so these apps can function - but what is that?
Roughly speaking, I need:- Authentication - simple user stuff
- A Video App - a place to browse, search, and watch a video
- A Customer Manager - a place where a customer can view information about their account, order history, etc
- A Commerce Thing - Invoice, Checkout, Payment etc
- "Brochure" stuff - Home page, pricing, support, etc.
In other words - a fairly modern web-based application. This list can apply to anything really - a website, a mobile app, a desktop app. In fact if this API works properly - we can build all of these.
But let's stay focused on the JS front - we have to start somewhere. There are 3 areas there that a Single Page App would excel at: the Video App, a Customer Manager, and the Commerce Thing. This is rich functionality that could use with less page clicks currently.
That's where Derick and I are going to start. We've both dug into EmberJS a lot lately (he more than me) and as I mention - we both know Backbone (again, he more than me). So we're going to use both and see what comes of it. Not sure which we'll start with - but we'll blog it either way.
Step One: The Data
Should always be step one in my mind... but then again I'm a data guy. There's a really nice PostGres driver for Node that I can use - but then I'll also need an ORM to get around the cycling of JSON to SQL.
I started to write MassiveJS and indeed I have it working but I started thinking...The main reason people use Document Databases with Node is because many of them, like Mongo and Redis (which is a key/value store), allow you to store your data in a JSON format. This means there is no translation to SQL and your client apps can send along some JSON and you just stick it in the DB.
In fact there's no reason I can't use both. That said - Mongo allows for some outstanding query functionality with Map/Reduce - Redis... well Redis doesn't allow queries really (favoring the generation of key/values upfront).
So since I know MongoDB - I'll go with that.
And I'm starting... well yesterday. I ported all of Tekpub's data to Mongo and it was a whole lot easier than I thought... which is the next post.
PS: If you're thinking "what about Production X and you need to roll out Production Y" - I'm not quitting my day job. Indeed - this right here is something I'll focus on "other time" on, which tends to be later in the day, or in the evenings when my wife watches Horrible Reality TV. Which I would do/have done anyway... this time it's just a kind of a public thing.
So - worry not. I have a ton of video here that I'll be cutting/loving/encoding. If anything I'll have more than you're used to.