We are actively using open source software to implement final solutions for our customers. This is not the way to save on something, in fact some commercial solutions might cost less on first look. This is a way to implement a future proof product that is guaranteed for future maintenance. And of course nowadays open source is also the key solution for security (well, when used right).

We do believe that common and widely used solutions should be free and open source. As it is known, free does not mean something will come without money. In some cases it might be worth it to pay money for support, maintenance and adaptations. We prefer to make our own contributions to open source communities. This typically happens in the form of finding, submitting and in some cases fixing of bugs. Or adding new functionality. However, what we are mostly proud about, is full projects that we contributed to the community.

TingoDB / Tungus - Embedded MongoDB compatible database

TingoDB is an embedded JavaScript NoSql database for Node.js and node-webkit. Its API and features are designed to be upward compatible with MongoDB and its driver for Node.js. Consider this seriously. It is not just a kind of MongoDB API only because it uses the same query syntax. It is a precise copy that allows to build applications that can transparently support both MongoDB and lightweight embedded data engines. It is even possible to adopt some derivative libraries that depend on MongoDB. Good example is Mongoose.js ODM library that can be connected with TingoDB using Tungus driver.

Safe(js) - Presently legacy library to solve JavaScript "callback hell" issue

Initially the module was designed to provide a set of handy functions to deal with thrown errors, callbacks and nodejs alike error passing (first function argument). The goal was to make code more stable, readable and avoid some routine calls. Idea is inspired by the Step library which catches thrown errors and converts them into callback function calls. Later was library was extended with full set of Async(js) library but with speed improvements and safe(js) error handling out of the box

Tinelic - Lightweight application performance, real user experience and error monitoring.

We are developers. We see a lot of benefits from using error reporting and app monitoring software. We tried to use many tools and nothing satisfied us. We tried to improve some of them but in the end we built our own. Everybody does the same ;). Tinelic is Node.JS application which works as backend for application and error reporting agents and as GUI. In order to simplify things we didn't do any complex data processing and fully relied on MongoDB scalability. It gives us flexibility and enough capacity for middle sized apps. For data collection Tinelic uses following agents:

• NewRelic APM agent (currently tested only Node.JS agent). Agent is used as is and just reports to Tinelic instead of the original server. Application performance and error reporting is supported.
• GetSentry (Raven.JS) agent for browser error reporting. Agent is used as is and the same report to Tinelic.
• GetSentry (Raven.NodeJS) agent for server side error reporting. Useful when you need only error reporting.
• Tinelic code for end user browser side monitoring (Ajax & Page load)

TinyHook - lightweight JavaScript message queue library

Library was created with a single goal - to provide reliable and lightweight distributed EventEmitter implementation. EventEmitter is a conceptual Node.JS interface for distributing events. Reliable for us means that an application should be able to consist of dozens of processes running hooks and handle millions of messages a day without issues, high CPU usage and high memory consumption.

TinyBatch(js) - safe way to execute sequential data retrieval server side

Very soon network latency might not be an issue anymore. However as of now executing of functions (REST calls) are suffering from network latency. This is especially concerning when functions can not be executed in parallel and have dependency on each other. We've made multiple attempts to solve this problem taking different approaches like preapproved or signed scripts pushed from client to server. Or "flexible" data retrieval approaches like graphql (which actually nailed down to available implementation and are more exploration friendly rather than flexible). Or use of limited scripting using Lua or Lisp. Primary challenge here is to provide flexible yet secure functionality which will also be safe to execute in server context in terms of resource use.