Small introduction

There are lots of different apps for storing and sharing data. Cloud storages, messengers, note-taking apps and so on. We all use and love them, but they have few disadvantages:

They work great when you need to store only files or only text, but information is usually more complex.

Collecting data together with someone is a frustrating process because it is often hard to understand who sent what, when and why.

Many services try to solve these problems with “add ons”. Shared folders in Dropbox or work chat in Evernote are just few examples. We believe that only a completely new interface can work.

About the project

In Staply you create interactive notebooks where you can work together and store anything. We’ve divided interface into two parts. Notes you publish appear on the left side. Our algorithm analyzes them and moves files, links and other meta data from notes to the right side.

You can browse through your notebooks with filters. With their help it is possible to display only notes containing files or links. After you found the link/file you were looking for you can get to the place where it was posted. There is also a simple text search for more direct cases.

Furthermore we’ve decided to make structure of the service as simple as possible. There is just one level of notebooks and that is it. So if I have a notebook called “company X” I can be sure that I should look for documents, related to that company only in this notebook.

In notebooks you can work alone or invite other members via email. Staply notes support Markdown and you can edit your notes at any time. This way you can avoid having too many notes in the notebook. It will contain only up to date and well structured information.

Technologies we used

If in short, then:

Hosting — Amazon Web Services;

2 instances EC2 — small for the test server, medium — for the production server;

S3 — for storing data;

Simple Email Service — for sending emails from the app;

DB — MySql (in the Amazon RDS).

We were gradually increasing traffic to avoid sudden increases of the server load and thus keep our servers alive. That allowed us to identify bottlenecks in the system and remove them without any emergencies.

Since the start of our development we used Amazon AWS. Ec2 m1.small for the test version and m3.medium for the production version. t2.micro with installed Haproxy for convenient routing and load balancing when adding new instances.

Memory usage in Passenger

With the load like that

We wrote server on Rails and launched it in combo Passenger + Nginx. Actually a lot of time was spent looking for the optimal server. We chose that one as the most stable from the memory consumption perspective.

We’ve decided to launch a MySql Database on the RDS server for daily backups. That gave us a possibility to increase the capacity of the system without having to transfer the data. Since people were using service from the early beta version, we had data in the base that we had to keep safe.

Simple Email Service (SES) in Rails integrates nicely with Action Mailer, and offers a free quota of 10000 messages a day.

Couple of words about design

All design of the project we’ve done in the Sketch app by bohemian coding. We’ve decided to do icons and illustrations in SVG, that way we didn’t have to worry about users with high resolution screens. We’ve then combined those SVGs in sprites to avoid flickering during state transitions.

That’s it. Would love to hear your thoughts and ideas.