Posted
31 July 2015
Category
Blog
Comments
0 Responses

Preface

Since 2006 I’ve been running a rock photography collective called Wannabes. We’re 15 photographers strong and have taken pictures of thousandsof gigs in Belgium and abroad.

Around Christmas 2013 our server crashed. Or no … it was deleted. My scatterbrain forgot to pay the bill, and instead of just suspending the account like our host normally did, something went wrong and it was deleted.

They tried to restore it, but it turned out they deleted the backups as well. We were fucked.

Good intentions

After the grieving we went to the drawing board and starting designing a new website. One that would be better than the old one. Even though we lost almost 7 years of pictures, everyone was ready to fight back, dive into their archives and upload everything.

To speed things up, I (the developer) choose to use a Tried And Tested CMS Solution™ you might know: Drupal.

Creating the backend in Drupal is fun. Just add the right modulus, create your entities (content types) and voila … you have a great CMS.

Our photographers started uploading all their images, and things went really well. For a while …

The fun ended while developing the front-end. Drupal theming was a pain in the ass. So many files, so many classes that are added to your elements. I know there are a lot of Drupal lovers out there, but it just didn’t cut it for me.

To make things worse … it was so f*cking slow. There’s really something wrong when you need to add extra things (Memcached, Varnish) in order to get usable page load times.

Enter Meteor

I’ve been loving Meteor for the past year. It makes developing web applications fast, fun and magic. I used it before for a very small content site for a Belgian TV-show called Boost, but I didn’t really know if it was usable for a large site with lots of relations between objects.

So, only one way to find out … try it. It wasn’t easy to throw all the work on the Drupal site away, but a hybrid (Drupal backend and Meteor frontend) was way too much hassle.

Creating the backend

So I typed meteor create backend and got going.

Creating a backend in Meteor is not as fun as doing it in Drupal. The task is quite repetitive and rather boring. Here’s a list of some of the packages I used:

  • materialize:materialize: because I got tired of creating Bootstrap-based interfaces
  • aldeed:autoform: creates forms for you, handy!
  • gildaspk:autoform-materialize: makes thoses forms nice in Materialize
  • aldeed:collection2: schemas for a schemaless database, needed to use autoform
  • tmeasday:publish-counts: I built my own pagination system, having counts of collections was needed.
  • todda00:friendly-slugs: automatically adds slugs to entities
  • reywood:publish-composite: one of my favorite packages, publish a collection together with its relations
  • cfs:filesystem: I like what they’re trying to build, but collectionfs can be a pain in the ass. I think I’ve encountered every bug in this package. If I could start again I’d useostrio:files since it focuses only on getting the upload done.
  • percolate:migrations: doing migrations the right way.
  • meteorhacks:kadira: great service for hunting down errors and optimizing.
  • meteorhacks:npm: access to the whole NodeJS ecosystem is nice!
  • meteortoys:allthings: totally worth the $99. No more opening the console when your app doesn’t do what you want it to do. Buy
  • percolate:synced-cron: there’s a lot of stuff running in the background, using this package seems cleaner than wrapping those things in a Meteor.setInterval
  • meteorhacks:search-source: together with the elasticsearch npm package get data into ElasticSearch.

The backend of the site is really crude for now, but it works. Drupal was much more user-friendly, but Meteor gives us more flexibility. Also writing packages for Meteor is more fun because of the rich NPM ecosystem.

Two things I wish I’d knew before I started:

The frontend

With the admin interface ready I could finally start with the site itself. We went through some design iterations until we finalized on the current one. Our goals were minimalistic, fast and clean.

Creating the frontend was the thing I enjoyed most. I just pointed the MONGO_URLandMONGO_OPLOG_URL to the backend Mongo instance and data was available within the app.

Development of the front-end went quite fast and it didn’t take long until the website was production ready.

Because we rely on images a lot and we need them in all kinds of different formats I used a service called resrc.it. They allow resizing & cropping images from your domain by passing arguments to an URL. They’re cheap and it works like a charm. They even offer a free CDN.

Architecture

Wannabes runs on a $64 Vultr VPS (4 CPU, 8GB RAM and 90GB SSD) and doesn’t break a sweat. The two applications are deployed with meteor-up and share the same MongoDB instance.

MongoDB runs locally, I tried running it on Compose.io but this was actually slower (probably because of network lag).

In front of the two apps is an Nginx server, acting as a proxy. The website is HTTPS-only (HTTPS is the future), so Nginx also adds to certificates.

There’s also an ElasticSearch instance running on the server, providing search to both applications.

And … backups are taken daily. We don’t want to lose everything again.

TODO: set up Continuous Delivery with CodeShip.io.

Conclusion

Meteor is at least as good as PHP or Drupal for a content website. It actually rocks.

Advantages

  • Pages load a magnitude faster
  • Everything is reactive.
  • No fiddling with AJAX-requests to achieve things like infinite scroll.
  • Same language on client and server
  • Lots of packages available
  • Blaze theming is great

 

Disadvantages

  • SEO: spiderable still seems like a hack, can’t wait for good server side rendering
  • Not click and play like Drupal