I was recently tasked with creating an Easter Egg in our application to launch a troubleshooting menu. In the past, I’ve done this by clicking on a sequence of items or on what appears to be a disabled icon a few times. However, this time I decided to try a different approach and implement a React hook that listens for the Konami Code input on the keyboard. Thus, the
useKonami hook was born. Here are the highlights:
At JetClosing, we recently released Version 2 of our app. For this release, we developed a whole new backend service that uses GraphQL for its APIs. This mini-series will cover the steps needed to set up your own production-ready GraphQL server in AWS, using the Serverless Framework, Node.js, and ApolloServer. It utilizes Lambda for running the server code, API Gateway to serve our GraphQL API, and DynamoDB as our backing data store.
To get started, you’ll want to make sure you have an AWS account set up and configured for Serverless.
Next, we’ll want to generate our service using one…
React hooks are a powerful way to supercharge functional components. However, beyond the
useEffect hooks, the examples for creating your own hooks are not very extensive. Let’s look at a practical example by implementing a file drag and drop on the whole window, which we’ll call the “Window Drop Zone”.
To get started, let's create our hook file. The naming convention for hooks is “use” plus the hook name, so let's create a file called
useWindowDropZone.js with a basic shell function.
Serverless is a great platform for managing your serverless infrastructure. It significantly reduces boilerplate code for setting up a service and defining functions. It even allows defining platform specific resources for things that aren’t supported out of the box. The problem is that service providers can require complex templates to support basic infrastructure. For example, AWS CloudFormation requires defining DynamoDB keys under two different fields for a single table. Therefore I created a plugin that would simplify table definitions, reduce boilerplate code and have smart defaults:
Below are two example
servlerless.yml definitions for a table described in the DynamoDB…
Serverless, a framework for managing cloud applications, is a very powerful tool. As your application grows in complexity, it can be difficult to manage deployment variables based on different stages (development, QA, production). Currently it isn’t easy to reference deployment specific custom or environment variables. I knew there had to be a better way of handling these variables while also making them composable. After some research into serverless’ architecture, I came up with a plugin that does just that:
serverless-plugin-composed-vars lets you define stage specific variable files. It overrides the variables defined in your
serverless.yml or in separate
At JetClosing we utilize decomposition and modular programming. As projects get larger, it’s important to clearly define the interface between objects by exporting the methods that make up that interface. Sometimes this can cause issues when trying to unit test that code, especially the private functions. The existing strategies for accomplishing this have their own issues:
Full stack developer specializing in React and React Native front ends, and AWS backends