While working at Dosh, I had pretty heavy exposure to managing NodeJS services running in AWS Lambda. During that time, I had learned a few things about the platform that can be leveraged when writing Lambda services. Some of these lessons may influence how you write services but can also give you some performance boosts. It’s important to note that some of the behaviors that I observed about AWS Lambda may not apply to other serverless technologies.

While working at Dosh, I had pretty heavy exposure to managing NodeJS services running in AWS Lambda. During that time, I had learned a few things about the platform that can be leveraged when writing Lambda services. Some of these lessons may influence how you write services but can also give you some performance boosts. It’s important to note that some of the behaviors that I observed about AWS Lambda may not apply to other serverless technologies.

While working at Indeed, I did a fair amount with gRPC. I became rather familiar with the Java, Go, NodeJS, and python implementations. During my vacation between jobs, I decided to revisit one of my old projects and try to migrate it to using gRPC. By doing so, I would be able to support a larger variety of request types (streaming, non-streaming, etc). When I started to look for good NodeJS code samples or reference implementations, I was rather disappointed with what I found. Many of the ones I could get my hands on only demonstrated unary methods and not any of the streaming API’s. After a lot of time digging through source and a few implementations online, I finally assembled a good reference.

In this post, I only wanted to detail what the method calls look like on both ends of the wire. There are some additional best practices that should be taken into consideration, but I do not plan on covering those here.

Component scanning packages can be both your best friend and worst nightmare. In this post, I will cover several bad practices when it comes to component scanning. In detailing a few of these anti-patterns, I will also offer a few better patterns that are much cleaner to use.

At Indeed, we always consider what’s best for the job seeker. When a job seeker applies for a job, we want them to have every opportunity to be hired. It is unacceptable for a job seeker to miss an employment opportunity because their application was waiting to be processed while the employer makes a hire. The team responsible for handling applies to jobs posted on Indeed maintains service level objectives (SLOs) for application processing time. We constantly consider better solutions for processing applications and scaling this system.

In my day to day development, I spend a fair bit of time working with Spring since it offers a lot of scaffolding to get a project off the ground. At Indeed, I spent a fair bit of time upgrading us from Spring 3 to Spring 4 and came across many good uses of Spring and many bad ones too. In this Bad Practices series, I will talk about some of these bad practices, why they should be avoided, and what you can do instead.

In a previous blog post, we described how to use our Status library to create a robust health check for your applications. In this follow-up, we show how you can check and degrade your application during an outage by:

• short-circuiting code paths of your application
• removing a single application instance from a data center load balancer
• removing an entire data center from rotation at the DNS level

Developers at Indeed have recently switched over to using docker for local development. Being one of the earlier adopters, I fell in love with the type of workflow that it enabled. It allowed me to create seamless environments between both my desktop and portable workstation. The tooling did this by allowing you to resolve container names as hosts in your web browser. For example, if I had a web application named indigo running on port 4000, I could go to http://indigo:4000 to access that application. After a few weeks of enjoying the simplicity of this development workflow, I craved a similar type of environment for some of the larger scale projects that I do at home. In this blog post, I will cover some of the basics that allowed me to enable this type of development.

LAAS is an abbreviation for LevelDB as a service. LevelDB is an implementation of a log structured merge tree (LSMTree) provided by Google. This data structure aimed at providing a high write throughput. When attempting to use LevelDB, I found it difficult to track down supported libraries in different languages. Additionally, the fact that it’s labeled as a database and doesn’t provide a service was troublesome. I wrote LAAS to make the adoption of LevelDB easy for any language. It does this by introducing a RESTful API to the underlying functionality. HTTP request libraries are a dime a dozen, which drove the choice for a RESTful implementation.

We are excited to highlight the open source availability of Status, a Java library that can report a system’s status in a readable format. The Status library enables dynamic health checks and monitoring of system dependencies. In this post, we will show how to add health checks to your applications.