Clojure in Athens: Skroutz
Comparisons and Clojure
by Jon Pither
This post is part of our Clojure In series, taking an in-depth look at companies across Europe who have adopted Clojure. In this article we look at Skroutz; a Greek ecommerce website comparing the prices of products.
We don't want a Clojure version of Rails!
Skroutz is a Greek ecommerce website used to compare prices of products. It is the biggest Greek originated website attracting millions of unique visitors per month. There are now versions of Skroutz running in Turkey and in the UK (scrooge.co.uk).
Skroutz started ten years ago and now has 150 employees with 20 based in Istanbul. They are predominately a Ruby on Rails company but they have started using different technologies such as Clojure.
Jon: Could you tell me how Skroutz started using Clojure?
Giorgos: I don't remember exactly. I remember that I didn't want to use Ruby for a specific problem - I've had very bad experiences with processes and segfaults with Ruby.
Jon: But why pick a dynamic lisp language with origins dating back to 1957?
Nikos: Giorgos was already a fan. We both liked Clojure and we were waiting for a chance to do something useful with it.
Giorgos: Ruby is good but it is not a good fit for everything. We've been adding new languages such as Python and Clojure along with some Java for wrapping Elastic plugins.
Clojure is used on one of the largest projects outside the Ruby monolith. We use it primarily to crunch user activity logs, a job that was done before using cron jobs and scripts writing to MongoDB.
Nikos: Giorgos led an effort to store all log data into Elastic cluster. We then wrote a Clojure service to crunch this data providing a layer of analysis on top of what the raw Elastic queries gave us. This allowed us to provide enhanced personalisaton functionality for our users such as recommending additional categories of products.
Giorgos: The same Clojure service also crunched stored user queries to power auto-complete and search suggestions.
Nikos: We wanted to experience Clojure and to use it on something real. We felt that Clojure fitted this problem of data crunching well.
Giorgos: It is very difficult to use a new language attached to a monolith. If you want to experiment you should find the right place, and for us this was a good opportunity; a Microservice.
Jon: How did it work out?
Nikos: Very well.
Giorgos: It's been running 18 months. It was initially a challenge - I had a team 4 juniors and no one knew Clojure, but the experiement went really went.
Nikos: We spent our Christmas vacation learning Clojure!
Giorgos: I thought it was impossible but then we did it.
Nikos: It was straightforward really - Giorgos came up with a skeleton and we started building functions on it - this went pretty well. The hardest part was what Giorgos did at the start; setting up a http server with Liberator then managing the application lifecycle and deployment.
We serve a lot of features from this microservice. We are very confident with it. This is the main thing we needed: confidence that nothing will break. It's easy to upgrade and predictable.
Jon: What's the future of the Ruby monolith?
Nikos:: There was a time when Giorgos wanted to rewrite the main search in Clojure.
Giorgos: We don't have the resources now to rewrite the monotlith in a big-bang approach. We will proceed step by step, looking for opportunities that present themselves, i.e. a new service, or a refactor of an existing one.
Ruby Vs Clojure
Jon: Could you elaborate more on Ruby vs Clojure?
Nikos: The turning point was when I start could focusing on the real problem rather than managing stateful objects and relationships as you would in Ruby.
Giorgos: The focus is on functions rather than objects; the transition is good.
Jon: What about the ecosystem of Ruby compared with Clojure?
Nikos: We currently have a strong solution with Rails and a strong ecosystem around it.
Giorgos: We don't need a Rails clone, but we need a flagship to attract people to the language. This could be Datomic.
Nikos: I miss the ecosystem of Ruby. In Clojure it feels more fragmented with lots of library choices and no clear winner. Some are maintained by a single person and can simply stop being developed. This is where having a big umbrella project would help.
Giorgos: It can be complicated to make a library decision. A company or software house should not be depending on a single person which is often the case.
Giorgos: No we don't want a Clojure version of Rails! I don't have time to answer this, but I would say we just need more flagship libraries.
Nikos: In general Ruby devs are switching to Elixir and some to Clojure.
Learning Clojure and Editors
Jon: What IDE do you use?
Nikos: We learnt Emacs for this project. We like it so much that we're now using it to edit our Ruby code too.
Jon: Would you recommend learning Clojure and Emacs at the same time?
Giorgos: To be honest, I wouldn't recommend learning both as it's very difficult. The advice I would give is to learn Clojure and then Emacs.
Nikos: We have a developer learning Clojure now. We told him to learn Emacs first for his Ruby code, and then we recommended Clojure Koans and some books. Then we paired up with him to solve some selected issues and bugs. This was the easy part.
State of Clojure
Jon: What do you think is the current state of Clojure adoption?
Nikos: I want to see more big projects, more blogs and different people using it.
Jon: What is the state of Clojure in Athens?
Nikos: Giorgos was a founder of the Athens Clojure meetup (I help run it now too - as well as Stathis Sideris and one other) and we host dojos in our office. The last one went really well with 25-30 people turning up, which was over our expectations. Athens doesn't have a lot of active Clojure programmers.
Jon: What's your view on the current state of Clojure the language?
Nikos: We are very interested in Spec and we are experimenting. We use Schema. We are also experimenting with ClojureScript but nothing real yet.
Check out the Skroutz engineering blog.
Sign up to the JUXT newsletter