Hello everyone,

As I promised that I’ll be writing blogpost every weekend after joining Leetcode for full time position, so here I go.

This week I worked on finishing up a major feature i.e. Improving filter’s functionality. It’s live right now. You can check it out on leetcode.

Leetcode’s frontend is built upon ReactJs. I wrote component logic for the filter functionality and Hercy, my colleague, connected all the dots and improved its UI. Now state of all the filters is saved in the URL itself. So, user can share or bookmark the URL to get the same state of the filter.

Moreover earlier filtering questions using search query used to work at frontend side due to which user was able to filter questions only using Question ID or Question Title. Filtering question by problem description is not feasible on frontend due to obvious reasons.
So, we decided to move the search functionality to the backend. Now we index all the question content and user is free to filter question using problem slug, problem details etc. Right now search isn’t that powerful like stemming doesn’t work. We will try to improve indexing even further.

Other than that, Accepted Solutions Runtime Distribution page was quite slow. Those who don’t know what that is, after you get ‘AC’ for a submission, open submission detail and there you can see this graph.

Everyone thought it’s due to lot of submissions on the OJ, more than 100 million. But fortunately leetcode backend is connected to newrelic, which is a performance monitoring tool. We saw a large no. of MySQL transactions happening on each GET request on submission detail page from the evening of 24th April. We checked the git commit history and found a new feature was deployed into that page at that time, which allows user to check other people’s submission with different runtime.

I fixed its performance by implementing on-demand submission retrieval which reduced SQL transactions by manyfold. Thanks to newrelic we were able to debug it out!

Moreover, I also learnt about how leetcode maintains user’s session. We use JWT for that. I can’t reveal whole implementation due to security reasons.
If you don’t know about JSON Web Tokens, then don’t forget to check it out after reading this blogpost. It’s really nice concept. Using JWT, you don’t need server-side session to check if user is authenticated or not. Don’t get me wrong. You might need server-side session due to some other reason but till this point, to check if user is authenticated, you don’t really need server-side session. You can store JWT in user’s cookies and you are good to go without persisting any session information server-side. Isn’t it cool ?

Other than that, we use slack for communication but our team’s account is on free plan due to which there’s limit on message history size we can browse. It happened to me 3-4 times that I scrolled up to check some previous message containing some important information and found that I can’t check messages any further. Switching to some other messaging service wasn’t possible as we have configured different Slack bots which send us many notifications like newly created issues on our issue tracker, any commit/branch updates on our VCS, CI updates, server status updates etc.

So, I decided to use Slack API to create a simple app which will receive every message sent in our slack team and log it into files. It isn’t complete yet as I was only able to spare an hour or so, to work upon it. You can check its source code here. It’s fairly simple.

Well that’s it for now.
Thanks for reading!