trivia: the real stackoverflow uses Redis as well for caching and to implement specific functions. I'm very proud of this since I consider stackoverflow one of the best sites of the whole internet, together with wikipedia and a few others.
Our "global inbox" and "frequented tags" features are built on Redis as well. There's a bit of traditional SQL behind global inboxes (mostly for persistence and backup purposes), however.
> I consider stackoverflow one of the best sites of the whole internet, together with wikipedia and a few others.
Though that has more to do with their community & content than their structure. Of course, SO's structure is part of the reason for its community/content (though I personally believe Atwood & Spolsky's star status was more important), but just copying that isn't going to get a similar site a lot of users or quality content.
Sure, when I say stackoverflow I don't just refer to the technology, but the community, how the site is handled by the founders, the original aims that resulted in the site, and so forth.
The interesting things are in my opinion that Redis is the sole backend, the code is simple, and no Redis operation was "forced" to do something that was not the natural goal. In practice this example shows how the Redis data model is a natural way to model complex needs without a line of SQL and without any need to setup indexes or things like that. I think this is a pretty important point.
Another interesting technical detail is that the whole site uses only an HTML template and everything else is done via javascript using jquery.
Agreed. It also highlights that you don't need an mvc frameworks for web app. Due to the popularity of framework such as Rails, many assume a framework is the only way to go. Powerful client JavaScript library is changing how people develop web apps.
Even though you are right and it is certainly not necessary to use an MVC framework to build a web-app such as this, you'll have to agree that the thoughts behind using such a framework are important (data/code/interface separation). But that doesn't mean MVC is a hammer for any nail.
Except that this webapp is absolutely built with an MVC framework — it's just that the M, V, and C are in different places than they are in the dogmatic arrangement.
MVC is not a fixed design, it's a legitimate universal Design Pattern (unlike most of the GoF book). It's a shared nomenclature for describing the arrangement of concerns, not a prescriptive blueprint.
Is this meant as a proof-of-concept, or a production system? What is stopping me from using Firebug to change the client and issue a 'rm -rf /'-esque command to Redis? Does Redis have some kind of permission checks? Is there some interesting solution that would provide a thin ACL layer in between the client and Redis?
It's a proof of concept, but at the same time all redis calls for this service is shielded by strongly-typed web services api (not a free command redis) so the only commands that are executed is what's allowed - the web services api would not be any different than if it was backed by an RDBMS.
Why would you provide an implementation with noscript tags? only 0.01% of your users will probably be affected. These are the users who never click or view ads anyway, why spent time for them while you could implement more important features?
It's an ajax site that uses static html/js for speed, i.e. there are no .aspx .jsp pages to generate dynamic html on the server. If this were a real app there would be.
Graceful degradation doesn't just mean "works without JavaScript".
This demo doesn't let you link to (or bookmark) a page or open questions in new tabs. For an app like Gmail that probably doesn't matter, but for something like this I'd say it's pretty crucial functionality to be missing.
Progressive enhancement where you add JS to improve the experience is a much better approach. That way you get all the basic functionality for free instead of trying to retrofit it onto the ajaxy app.
Now that you can manipulate the address bar with pushState [1] you can even make these enhancements completely transparent.
Is there a way to make it degrade gracefully? The problem I see is that you can't have the JS and non-JS parts have the same URLs. The JS part will have urls like thesite.com/#question123, whereas the non-JS site will have urls like thesite.com/question123. So now you have two urls for each page, giving problems with search engines (and I think search engines will consider thesite.com/#x the same url as thesite.com/#y, and only load one of them).
Yeah if it were a real app I would definitely go through the effort of having it degrade gracefully and crawlable. Although for those interested Google has a proposal for crawling Ajax sites: http://googlewebmastercentral.blogspot.com/2009/10/proposal-...
This demo also has a C# middle layer that implements a REST web service and an ORM; it's not just datastore + client-side javascript app (like CouchApp).
Its funny when people use the term 'ORM' when there is no ORM in sight (I know I do it to :). BTW there is no 'Relational' and no 'Mapping' in the C# Redis client, For max speed POCO objects are just serialized as JSON or have their primitive values stored in Redis's Sets/SortedSets.
I said ORM because the github project description says "...built with ServiceStack, C# RedisClient, OrmLite...". Just realized now that the SO clone is just one of several sub-projects within that repository, sorry.
Give it some CSS3 love too: get rid of that body background image and use box-shadow, also, download button is trivial to implement in CSS and will degrade gracefully.
Can't we come up with a nice way to get people to move to modern browsers? IE6 and IE7 should both fall below 10% this year. With a little prodding IE9 could become the least supported browser within a year, and IE9 is going to be a pretty good browser.
Saying so doesn't make it true, as-is that's a pretty baseless statement - lets see a 'better' example couch app that does the same thing - as we can see it has only taken 1 page of code to do this in redis. Next?
redis is a k/v store that will force you to write a lot of code to get the results you want out of it, people use it for purposes like caching, not storing your main content which you'll want to query in complex ways.
meanwhile couchdb is just more complex enough to make things easier, and it features database side authentication which will allow you to write full client side apps, which seems like what this author was going for here.
anyway it just seems to me like couchdb fits the use case here perfectly. when i wrote hipchan i used mongodb because I had server side code to auth, no bias here...
While I didn't make the suggestion initially, I can see where it may have come from and might be able to expand on it some.
couchdb has a concept called couchapp (think rails for webapps written in javascript) which allows the entire application from data storage on the filesystem to presentation in the browser to only require the couchdb process and the web browser. The data is automatically ready for bidirectional (or multidirectional) replication anywhere from offline apps to cloud hosting providers -- all active.
It purports to do for your web application what git did for your application development -- you can clone just the app from one DB to another, or clone the entire DB for backups, offline work, or even peer-to-peer production hosting or web.
I haven't done web apps very much myself in a couple of years, but that's one area that's a bit tempting for me since the ones I have been interested in have peer-to-peer data accumulation and offline work + synchronization needs.
* They all require two servers running (redis + a web server)
* None provides a framework for building an application.
* None provides n-way replication.
* None provides offline support.
I get that they do mean you can build a web app. The question above was why it would make sense to use couch instead of redis. The primary answer is because the database already does most of what you want (including serving the HTML to the web browser) since it speaks the same language as the eventual client.
>They all require two servers running (redis + a web server)
So? separating web service access to the datastore is simply separation of concerns and just good modular design. A redis hybrid solution is still going to be faster than Couch.
>None provides a framework for building an application.
There is lua scripting available in some of them and the application fx is generally on the client.
>None provides n-way replication.
Out-of-the-box Redis supports trivial (as many as slaves as you want) replication.
Perhaps I am reading the post title incorrectly. What DID they really clone? Oh, title like "created a Q&A site engine using Redis and jQuery, and styled it to look a bit like StackOverflow, whoop-de-doo" is not catchy.
Q&A sites are not about the code, they are about the people, asking and answering the questions. It's nothing without the community.
