New Public-Facing Website, built with Seaside and GemStone/S

We’ve just helped launch a new public-facing website, and it’s entirely built with GemStone and Seaside. The site is OurCatholicNeighborhood.com, and it provides content-managed pages for Catholic parishes, hospitals, schools, and charitable organizations. The site is supported by advertising, but not in the traditional sense — it’s more like “back of the parish bulletin” advertising. Behind the scenes, there are numerous management and review tools with hierarchy-based access control. This is all found under the “local” area, which is the dominant area of the site at present.

The site is currently running on Seaside 2.8, but we have plans to upgrade to 3.0-rc1 now that GemStone 2.4.4.1 is out. The web front end is lighttpd (naturally), and it integrates with Authorize.net using a cURL binding built in our own custom FFI (very similar to Alien, but hacked for x86_64). We built it in Pharo and deployed to GemStone; the GLASS environment (coupled with our own unit tests) made this pretty easy.

The entire project took one highly-distracted developer (me) 6 months to complete.

In a way, it’s significant to note what we’re not doing in this app:

  1. We’re not using any render caching: every page on the site is built on the fly every time it’s requested.
  2. Search results are not cached; every time a user uses the search bar, we scour the entire object tree looking for matches. Granted, this is a limited search — but for the number of instances we visit (belonging to 9 or 10 different classes), the system is surprisingly snappy. In my experience, SQL queries of this sort are nowhere near this fast.
  3. We’re not using any GemStone performance enhancements; this is an out-of-the-box configuration.
  4. We’re not currently using a paid license; everything we need (for now) fits within the scope of the free web edition.
  5. Static files are not (currently) hosted elsewhere; all images, stylesheets, javascripts, etc. are all served by GemStone. If we need to, we can move these to Amazon S3 in a matter of minutes (ain’t resource URLs handy?)

The site is still very much a work in progress, as all sites are, but I thought it worth publicizing since most of our other Seaside apps are private. As is often the case, the people funding the website development didn’t care what technology was used to implement it — so long as it was up to the task. This gave us an opportunity to throw our favorite set of tools at the problem, and (so far) everyone is extremely happy with the results.

Benedictus Iesus in sanctissimo altaris Sacramento.

Advertisements

5 Comments

Filed under GLASS, Seaside, Smalltalk

5 responses to “New Public-Facing Website, built with Seaside and GemStone/S

  1. Pingback: New GemStone/S and Seaside Site « (gem)Stone Soup

  2. andy burnett

    Wow, that is very fast indeed. I have a couple of questions:
    1. Are you using a commercial hosting company, and if so, who are you using?
    2. Are you managing the registration and log-in process through Glass too, or is that a separate system?

    The reason I ask is that we want to build a seaside system with user registration etc., and I haven’t found anything off the shelf that lets me do that.

    Cheers

    • We host on a dedicated box at Rackspace, so the hosting environment is completely under our control. As for the user registration process, that was all custom-built in Seaside.

      Even if there were some off-the-shelf toolkits for user registration, I doubt we’d use them. Every app has a different set of requirements for user registration, different requirements for review/confirmation, different data models under the hood, etc. By the time you learned how to use somebody else’s framework and got it working with your models, you could have easily built your own.

      • andy burnett

        Thanks for the info. I assumed we would have to roll our own, but I just wanted to double check.

        I notice that the login system doesn’t seem to submit the details via SSL. Is that a limitation of the lightpd, or did you just not feel it was necessary?

        Cheers

      • SSL wasn’t deemed necessary for this app; we may add it later. It’s certainly possible with lighttpd and FastCGI. Whether the request comes in via HTTP or HTTPS, the request gets forwarded to the Seaside backend (which can view the current request’s protocol and redirect the user into/out of SSL mode).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s