Inside Quandora’s technology stack (I): Core services

This post is the first of a series of 4 aiming to giving a peek inside the technology behind our software, Quandora Questions and Answers. We are covering the following topics:

1. Core Services / Runtime Environment
2. Web UI / Mobile UI / REST API layer
3. Build System & Integration Chain
4. Test Framework

Core Services / Runtime Environment

Quandora, the application, is composed by several OSGi bundles running on top of Equinox, an implementation of the OSGi’s specification (and an Eclipse.org project). We use Nuxeo’s extension point system to bind those components together. (Nuxeo is an open source content management platform. We use some of its core components as a base for our content management infrastructure).

In our case, OSGi allows to separate concerns between bundles and swap services to get purpose-built Quandora instances (on-premise version without our SaaS-related services, background jobs only, mock mail service for testing, etc.)

Plus, as we have code hot-reload working in our framework, the dev experience is pretty nice.

Runtime Environment

We run on Equinox & Jetty and it plays well as a lightweigth runtime environment: no clutter and we can add features as we need them.

Content Persistence

All the Quandora content is persisted using Nuxeo Core into PostgreSQL.

All the content is stored into the repository: questions and answers, obviously, but also user profiles, comments, site customization, etc. It enables a high level of flexibility in schema change and pretty cool services like transaction management and versioning while offering a great level of reliability. All content that is here to stay goes into the repository.

PostgreSQL is the final host of our content, including the activity log (storing all data related to actions and change in the content) in a separate database.

We have also completed the repository with a custom cache system based on Redis and an indexing engine based on ElasticSearch, so we practically never hit the database for any read-level operation.

Transient Storage: cache & full-text index

Redis is our main storage service for transient content:

• cache for frequently accessed content coming from the database, with automatic update when content is updated
• async jobs (and associated status / data) for the distributed job broker
• flash messages for users (to give feedback to users after some actions: comment posted, question voted, badge received), etc.

ElasticSearch powers most of our listings and search capabilities. Most of the interesting text-based content is indexed into Elastic Search and it enabled us to create a pretty awesome faceted search navigation and fast listings. So most of the navigation pages are served from ElasticSearch content.

Coming up next…

That’s it for a first look at how we’ve built Quandora. I’ll explain in the next part of this series how the UI and API layers are built and what powers them. Spoiler alert: we’ll talk about Jersey/JAX-RS, Freemarker, Apricot Web Framework, Bootstrap + Bootswitch, jQuery and AngularJS!

We’re pretty happy with the technology choices and we are planning to open source part of the infrastructure we’ve built:

• DQueue: a Redis-based distributed job broker
• Reflash: Redis-backed flash messages for instant in-browser user feedback and our set of OAuth2 clients.
• Our set of OAuth2 clients

Questions? Suggestions? Critics? Praises? We’d love to hear from you! Leave us a comment or write to us at contact@quandora.com.