Part 1 (https://news.ycombinator.com/item?id=9605966) and Part 2 (https://news.ycombinator.com/item?id=9605991) focused on the architecture of GuruFoo.com. Here are some of the lessons we learned along the way...

Understanding your platform is a must. Early on, we did some very simple SQL access, and basically just relied on what JPA provided. This was done because we were really focused on getting the whole of the application developed. In the end, we made heavy use of native SQL queries for some items. The performance was night-and-day compared to trying to shoehorn JPQL in there somehow. The same holds true for JSF. If you don’t understand the JSF lifecycle or how pages are rendered, you can end up really wasting resources. Unnecessary CDI Conversations, too much in Session, full-page reloads when you could’ve used Ajax… We’ve run into all of those problems and more.

Always spend a lot of time thinking about your application architecture. Design patterns exist for a reason. Conversely, anti-patterns are called anti-patterns for a reason, too! Case in point: The Open Session in View pattern for data access. We made the mistake of leveraging this early. While it does have its merits, we found that it masked a lot of latent problems in our architecture. Sometimes you want that transaction to commit right now! The result was a LOT of additional headaches and testing to pull that code out and replace it with proper transaction management and lazy resource loading.

Okay, that’s it for now. Please feel free to post your comments, questions, and especially criticism! See something you think could be handled better? Go ahead and say it! We’ve got thick skin, and always enjoy looking at things from a different point of view.

And, as always, we’d love for you to check out our site. Take a look at GuruFoo.com (http://www.gurufoo.com) and let us know what you think!