‹ back to Testimonials

Reffeed


Reffeed

Reffeed is a global B2B reference network and community portal. Built for B2B oustourcing service providers and seekers, Reffeed provides effective search and presentation tools to connect companies and help service providers present their business references with the help of their clients' confirmations and testimonials. On Reffeed, companies can define their services and expertise and get endorsements from their clients through a reference approval workflow. This way, Reffeed aims to be the unique trustable B2B reference network.Founded in 2014 by Dreamrain, a software company located in Germany and Turkey, Reffeed has a small team of five people including Çağatay Kalan the CEO, who is also one of the three founders of Dreamrain.

Who are you? (Name, company, position)

Çağatay Kalan, CEO of Reffeed (reffeed.com), a global B2B outsourcing reference network.

In what kind of project / environment did you deploy RavenDB?

Reffeed is a ASP .NET MVC web application running on a Windows Azure virtual machine. Since we have just launched Reffeed, we have only one web server on which Reffeed web application and RavenDB runs side by side.

What made you select RavenDB as the NoSQL solution?

In Reffeed,we have various types of activity feeds and notifications. To store these we need a schemaless database. In addition to these, we store Quartz job data, RabbitMQ message data and users’ page visits and search actions. Some of these features require schemaless storage and some also require fast id based queries which are the two most important solutions provided by common NoSQL products.

How did you discover RavenDB?

We have been following Oren’s blog posts for a long time. That’s how we discovered RavenDB. But we have also been using MongoDB and Lucene ( and Apache SOLR ) for some time and we were in search for an integrated solution which we could inject into our own framework’s unit of work system.

How long did it take to learn to use RavenDB?

Just after we tried RavenDB for the first time, it took a few days for us to create some basic internal web applications. Then we decided to port one of our ongoing projects which was planned to process millions of records and provide real time analytics to RavenDB. During that time, we had the chance to dug deeper into RavenDB internals and it took about 2-3 weeks for the whole team to learn how to develop RavenDB applications effectively by designing document schemas, handling relationships, creating and managing static indexes, using patch requests, handling events, applying optimistic concurrency, using batch inserts and more advanced tasks.

What are you doing with RavenDB?

We are using RavenDB for the main storage system for user actions, activity feeds, async message and Quartz job states, page visit tracking data and user search data. Reffeed also uses Microsoft SQL Server for the core domain persistence. At some parts of our application, we have a hybrid solution which allows us to store entities to SQL database and match some RavenDB documents with these entities based on shared identifiers. This way, we can query some basic data from the relational database and then get denormalized and more complex data from RavenDB quickly. This prevents us from storing list or dictionary like structures to multiple separate relational database tables especially when multiple joins are not required for the presentation purposes.

What was the experience, compared to other technologies you used before?

We have our own framework “DreamApp” which abstracts our common tasks such as dependency injection, repository and unit of work functions. DreamApp already had extensions for EntityFramework and NHibernate but other commonly used NoSQL solutions were not suitable for being integrated into a UOW system. With RavenDB, we could achieve this. Since Raven’s session is a unit of work by itself, it was really easy for us to wrap Raven mechanisms with our repository and uow architecture.

We know that it is not advised by the Raven team to abstract RavenDB but for some very basic CRUD applications, it was important for us to use our own framework so that our developers program against a standard API and it was really very easy for us to achieve this.

Integrating RavenDB was an easier and quicker solution compared to other products and we did not have to write additional codes to handle storage errors and rollbacks thanks to Raven’s transactional storage capability and ability to enlist into transactions.

Since we have been working with Lucene and Apache Solr for many years, RavenDB was the most effective and integrated solution for our database query and full text search requirements.

What do you consider to be RavenDB strengths?

  • Transactional storage
  • Easy Integration to .NET applications
  • Minimum configuration requirements for basic applications
  • Fast inserts thanks to asynchronous indexing
  • Full text search capability thanks to Lucene indexes

What do you consider to be RavenDB weaknesses?

  • Insufficient documentation
  • Smaller community and long response times to issues ( compared to other common NoSQL tools )

Now that you are in production, do you think that choosing RavenDB was the right choice?

Currently we are in public beta phase and we don’t have large loads but theoretically, RavenDB’s architecture seems to be the best choice for us. Our performance tests also showed that it can handle way more than our estimated loads.

What would you tell other developers who are evaluating RavenDB?

RavenDB can help you build .NET applications in a few days with little learning and configuration. Its schemaless architecture helps you store and query for complex entity structures easily. With RavenDB, you can develop most common tasks of today’s web applications within a shorter time period compared to working with relational databases. For the remaining, more advanced, reporting-like tasks, Raven provides alternative ways of importing data to SQL databases. In Reffeed, we made a decision to use relational database for some parts and Raven for the other parts but this is not a common way of using NoSQL databases. We currently have five other web applications using just RavenDB for persistence and we are so happy with it. Aside from the persistence of primary application domain, RavenDB is the best way of storing user and application settings, session related data, activity and auditing data and more so we have left behind the days when we created separate database tables for all these secondary level persistence tasks.