We love tech. We love trying new tech. We embrace it and experiment with it. That said, we let the project decide the technology and never the other way round.

The usual stuff

NodeJS

We used Java and PHP for many years. (Didn’t everyone?) At some point, we started our first Node project for full-stack development. We don’t know about you, but for Node, the speed of the Javascript runtime, coupled with the event-based parallelism makes it a very powerful server-side platform. This said, we use the very popular and flexible Express or more modern SailsJS to develop web applications. All in a day’s work.

Angular front-ends

After using JQuery and Dojo extensively for a decade, we gaped as Angular took us back to the old thick-client programming model. We worked our way through to the latest Angular versions, cursing as each release broke compatibility. We start with ready themes instead of building from the ground up. Today for all browser-based UI, it’s only Angular for us, no curves.

Hybrid mobile apps: Ionic

Do you really want to run two separate teams to develop two parallel versions of your mobile app for Android and iOS? Since 2012, we have tackled every nay-saying client who wanted to go native with their apps, and we’ve won fans for Ionic. Code once, run on both mobile platforms. Do everything a native app can do. If you know what you’re doing, Ionic is a promise delivered. We have moved out of native app development completely.

Java, Spring and SpringBoot

What do you do when you begin work on a microservices architecture for one of the biggest BFSI companies? You choose SpringBoot, given the large enterprise applications. With SpringBoot and Netflix’s microservices stack we could implement robust and flexible system architecture. SpringBoot and chill.

C

Yes, we do C too. Yes, in the midst of all this Ionic and Angular. IoT software development, high performance software product development, system daemons — they all need C. Our C programmers are a different breed from the web application teams, but they don’t want to do anything else. But then we like discussing pointer arithmetic and malloc() matching free().

PostgreSQL

If your database is architected the right way, PostgreSQL can be scaled to thousands of inserts per second, at billions of rows. It works well even on a single node with a modest amount of RAM. With HStore and JSONB, PostgreSQL can be used as a non-SQL database as well. GiN and GIST indexes are some of the most flexible index structure to have in an RDBMS. Little wonder, PostgreSQL has become our go-to database. We use it for typical web applications. We use PostgreSQL cluster for multiple TBs of data stores for financial data. We use it for storing and indexing geo-locations and for time series data for IoT as well. Quite a multi-tasker, this one.

The surprise packages

Non-SQL Databases

We have been using Solr since 2010 in production applications. We have also used MongoDB and CouchDB for specific situations. We have often used Berkeley DB instead of relational databases for large dataset problems.We have used the ELK stack to build a reusable solution for log aggregation, and have worked extensively to integrate ElasticSearch with business applications. Like we said, we’re always embracing tech.

Parallel processing

We regularly use parallel processing in the applications we design and build. This could be as simple as forking Unix processes to share the workload, or as sophisticated as PRISM. We have often used multi-threading in Java code. Our brains use this function while thinking of what to order for lunch too.

Distributed applications

We have built systems where components executed on separate servers and communicated among themselves. We have sometimes built our own simple message-based communication layer. We have worked with Java messaging implementations (ActiveMQ, Qpid) recently and MPI backbones for HPC clusters. Always on the ball.

Cloudy with a chance of meatballs

We have been using Amazon EC2/ EBS/ S3 since 2011 for production applications. More recently, we have set up systems on Azure, and designed systems integrated with Azure AD, Azure Database, and other awesome stuff. We’ve done 20 transactions/second on AWS instances with our own PostgreSQL instance. Twenty may not sound like much, but 20 per second is a very large number.