I concluded my GraphQL series for the Omada Health Tech Blog by sharing some tips we found for implementing GraphQL APIs using the graphql-ruby gem. These include the code organization structure we chose and how we were able to add GraphQL-specific details to our existing request logging system.
This is my second post for the Omada Health Tech Blog on adopting GraphQL. In it, I outline the various benefits we found GraphQL brought compared to how we traditionally implemented APIs, including better documentation, mobile client support, and performance.
Written for the Omada Health Tech Blog, this post explores the process I helped lead at Omada of investigating and eventually adopting GraphQL for several important features. It covers our decision making process and our strategy for incremental adoption. It also touches on our approach to scaling GraphQL's learning curve and bring various engineers on the project up-to-speed.
Thankfully, there are a few techniques you can utilize to get the browser downloading your critical assets even before your server has finished generating all of the page's HTML. One of them is called early flush, and it involves sending down the HTML for a page in separate chunks instead of all at once. In this post, we'll take a look at how early flush works, how you can use it to get the browser downloading assets early, and how big of a difference it can make when your server has a lot to do.
I've been working as a software engineer, primarily focused on front-end development, for a few years now. I recently started a new job as a senior front-end engineer at a company called Omada Health. During my job search, I spent a lot of time trying to figure out the most important questions to ask when applying for a software engineering job. I was looking for somewhere that would facilitate my growth, where I could make an impact, and where I would enjoy my work. So far, I believe I've found a company that meets these qualifications and then some. In this post, I want to present some of the questions I asked during the interview process that helped me make the decision to choose Omada. These questions are roughly divided into categories including company info, people and processes, product, and engineering. I think they represent a good baseline of the info a software engineer needs to decide on a new position. I'll go through each of these categories and explain their questions.
In this post, I'm going to walk through implementing an image zoomer component. It's basically what you use on a site like Amazon to get a closer look at an image by hovering your mouse over a thumbnail.
I coauthored this post for the LinkedIn Engineering Blog, providing details on how we defined reusable style patterns for our web implementation of LinkedIn's design language, Art Deco, and how we documented them in our pattern library documentation.
One challenge I wanted to tackle as part of this project was to get my blogging app to support both server-side and client-side rendering (make it a "universal" app). In my experience, server-side rendering is great for enabling a quick initial render and client-side rendering is great for quick subsequent page views. As part of achieving this goal, I discovered a few handy tips. I'm going to share these in the hopes they'll be of help to others.