I recently came up with very convenient component – likeastore/notifier. Notifier is easy to setup Email, SMS and Push Notifications Server. It’s been open sourced few month, very specific to Likeastore needs, but due to great contributions it became very generic and can be used in your projects as well.
Remember my success story of moving from MongoDB full text search index to ElasticSearch? After about one month of work our search service unexpectedly stopped. I received a bunch of emails from Logentries and NewRelic that server is no longer responsive.
Once I logged on to DigitalOcean account, I’ve seen message from administrators that server is sending a lot of traffic (UDP Flood), very likely compromised and therefore stopped. The link they give as instructions to fix the problem was quite comprehensive, but the most important info was in comments. A lot of people who were hit by problem had ElasticSearch deployed on their machines.
Last year, July 2013 public version of Likeastore been released. It gave momentum to change the mind, went out of comfort zone, reconsider priorities and literally change my life. Earlier I blogged about transformation of Likeastore from side project to startup.
Today, I want to share some info on where are we now and lessons I learned so far.
Recently we’ve released Google Chrome extension for Likeastore that allows to extend your Google search results with relevant information from your likes. Development of Chrome extensions appeared to be interesting process, but essentially it’s nothing more as web development, since primary technologies are still HTML/CSS/JS.
The most important thing for every startup are metrics. In web application we use Mixpanel together with Google Analytics and Seismo. For browser extension I also needed some simple metrics, like “usage”, “clicks”, “shares” etc. Unfortunately, if you just try to reference
mixpanel-2.2.min.js it won’t work.
We use MongoDB as our primary data source in Likeastore and went the way of MongoDB Full Text Search. Everything were fine initially, but after a while it became obvious that MongoDB FTS could not satisfy me any more.
I knew about search oriented storages as ElasticSearch, Sphinx, Solr, etc. but the migration process always seemed a bit scary to me. After a bit of elaboration I decided to go with Elastic and the migration was quite fun and not so difficult as I initially expected.
Recently, I’ve released small Express.js extension for easy switching application to
maintenance mode. Sometimes, you just want to run patch against database or change the infrastructure of product, but instead of showing blank
nginx 503 error page, you want to have nice looking HTML, saying will be back soon.
maintenance package is now available on npm and you welcome to use it. But I would like to share the way I developed and test it.
The year, seems to be a huge period of time. It is, but I have to say it’s only few last months (from the middle of December till today), we are fully dedicated to project. It’s been great ride so far, so I wish to share some interesting moments.
API is heart of modern web application. It’s all about to make it easy to consume, scale and make sure it works as expected. Currently I follow “all open API methods must have tests” (AOAMMHT) principle. I used to work with .NET technologies, where testing of API’s was about calling methods of corresponding controller object, which typically was unit testing – mocking up all controller dependencies, setting up expects of returned values.
I’ve changed my mind on testing with Node.js/Express.js development. For API’s I prefer “end-to-end” testing: setting up user account, authentication, HTTP calls to server, real calls to DB and serving JSON payload back. API’s have to be tested from consumer point of few to be able to give some meaningful results.
One of the components I currently work on called
collector and it has no tests. Collector is all about of building queue of tasks, executing them and store data to database after. Tasks are HTTP clients that requests API and process transform responses into generic forms.
I’ve started it with tests using nock component to mock HTTP requests, but quickly I found those tests both hard to write and no real benefit cause real responses that could broke it differs from ones I mock inside the tests.
In the same time, I regularly change that component and after changes and deployments I pretty quickly see the regressions and non-expected behavior, cause all information I need is inside of application logs. I call that “Logs Driven Development”.
Node.js/Express.js is great for Web API’s and applications. In contrast to known enterprise technologies, Node.js is very special. It’s single process/threaded environment. In case of unhanded exception occurred Node.js virtual machine simply stops, leaving application in unresponsive state.
async nature of Node.js
try/catch not always works, even with
domains and stuff you have a chance that application crashed on production while you sleep.