Introduction

GraphQL is growing in popularity because it allows applications to request only the data they need using a strongly-typed, self-documenting query structure that enables an API to deliver data that can evolve over time.

Unlike traditional REST APIs, GraphQL exposes a single endpoint to query and mutate data. Upon learning this, one of the first questions that comes up for many developers is: “How do I implement authorization and authentication in GraphQL?”

Continue reading …

Customizing your terminal is a fun way to streamline and personalize your digital workspace. People are more productive when using tools they enjoy and tend to value things they made themselves at a premium, but, as with all technical adventures, it can also be a little tedious to track down all the relevant documentation. This tutorial assumes you’re using zsh as your terminal shell. If you’re not sure what shell you’re using, the following will print the default shell path:

$ echo $SHELL

Continue reading …

Deployment, despite being an essential task, can be a confusing part of shipping an application. Depending on your stack, there could be a plethora of tools out there or… none at all. Unfortunately, Elixir falls into the latter bucket. Despite having a heart of gold, the language is still obscure, and that makes the process of deployment a tiny bit harder.

Addressing this problem may have been the reason for incorporating releases into version 1.9 of the language. Since the version bump, Elixir Releases have received the official blessing of the core language team. That means that deployment will finally be a piece of cake… right? There’s a caveat. While releases are meant to be self-contained executables, they still call out to native system libraries to do things like open TCP sockets and write to files. That means that the native libraries referenced at compile time need to be exactly the same as the ones on your target machine. Unless you can guarantee that your workstation and cloud are exactly the same, releases can seem like only half the promise of a stress-free deployment.

Continue reading …

Starting with Rails 6, Webpacker became the default asset compiler, replacing sprockets–better known as the asset pipeline. While the asset pipeline was a big step for its time in making it easy to package JS, CSS, and images, webpack has matured enough to do all of the above and more, due to modern JavaScript’s support for modular imports and exports.

Why Migrate?

Personally, the biggest benefit of webpacker is how it encourages me to think about structuring assets as components so that they are theoretically portable and do not rely on hidden globals. And by using an extensible tool like webpack under the hood, you can take advantage of popular plugins and customizations to tune what you need – like deduplicating shared imports, in both JS and CSS. Finally, you’re not limited to just extending webpack: it’s much easier to tap into the huge ecosystem of npm packages.

Below is a breakdown of how to start moving from sprockets to webpacker.

Continue reading …

Say we have Project X and Project Y that require Postgres 9 and Postgres 10 respectively. These projects aren’t using Docker to manage their Postgres dependency so it is up to each developer to manage this themselves. How do we get different versions of Postgres running simultaneously on our workstation without making any modifications to these projects? One easy way is to use Docker Compose.

Why not Homebrew? With Homebrew, installing multiple versions of Postgres is easy, but running them simultaneously is cumbersome. With Docker Compose, both installing and running are easy. Note that we’re not “dockerizing” the applications themselves; instead, we’re using Docker Compose as an alternative to Homebrew to fetch and run Postgres. Continue reading …

What is a pull request?

Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

Github

Many development teams use pull requests as a way to control and socialize the code changes made for a given project. They serve as documentation for the development process as well as a tool to discuss and review the changes. They can also inform future developers about the reasoning behind a particular implementation or coding pattern by including notes about the current state of things when the pull request was originally submitted.

Continue reading …

At Carbon Five we try to be agile about our technology choices and pick the simplest tool for the job at hand. That means that even in 2019, the era of React and Redux and GraphQL and all the other fancy tools for client-side web applications, sometimes the best tool for our clients is a good old Rails app, serving HTML.

Often the vision for the project pushes us towards a Single Page Application instead — maybe the app is going to be highly interactive or include realtime data, or the client is already invested in a front-end framework. In those cases, of course, we’ll reach for React or Angular or Vue. But for the traditional CRUD app that just needs to show some data and let users update it, a small team of experienced Rails developers can get an idea to market incredibly quickly.

Continue reading …

When writing React components, we sometimes need access to lifecycle events to handle a variety of side effects: fetching data on mount, sanitizing props when the component updates, cleaning up before the component unmounts, etc.

Continue reading …

Each team has their own tolerance for what is and is not a reason to request changes on a PR and block it from being merged. This may be rooted in process, fairness, and expediency, and may be a company or team decision. Whatever your personal philosophy may be, the team as a whole and often the company has to come to some sort of consensus as to what constitutes a reason to block a PR. Over time, I’ve gotten a little more “block happy” and I’m going to talk about some of the advantages and pitfalls of blocking, and give you a mega list of reasons you might want to block a PR.

Continue reading …

In smaller projects, React offers snappy performance – the virtual DOM diffing means updates can happen quickly and for the most part, things just work. But, particularly when you’re dealing with large data sets, things can bog down as every render loop causes many unnecessary renders of components which have not actually changed.

React Dev Tools comes with a profiler that can help pin down the problem, and React 16.8 came with some features to make it easier to improve performance of functional components. But to use these tools effectively you need to know what the problem is and how to find the culprit.