DEV Community: Alec Brunelle

Running SQL Migrations Before Booting Docker Compose Services

Alec Brunelle — Tue, 29 Sep 2020 18:45:55 +0000

Having a great local development experience is critical to happy engineers. Developers are happy to come into a codebase and start hacking away at problems, as opposed to dreading picking up their laptops. As services become more and more separated into separate "micro-services", new problems arise. When I look back on my short career, one problem that has induced me a lot of pain are SQL Migrations and how they should work in Docker Compose. Ideally, they should run before your web apps boot so they have access to a well-structured database. Your strategy to make this happen may be different for each environment, in this post I'll cover your local experience which easily extends to CI and I'll also touch how to do this in production.

A Bit of Background

I ran into this problem when we started to adopt Apollo Federation into our stack. One gateway service lives in front of our other GraphQL services (which have their own databases). This gateway is what the client-side apps ("Web Browser" in diagram) queries to get its data. For clients to start using the gateway API every dependent service must be up and healthy.

My goal is to start the entire set of services in a deterministic manner, have each service wait until its dependent service is running and healthy. I'll focus on the database and migrations in this post but the concepts here extend to any service having dependencies on another service.

A typical Docker Compose file which runs the products service with it's migrations will look like this:

version: "3.7"

postgres:
  image: yourorg/postgres
  command: postgres -c 'max_connections=1024'
  expose:
    - "5432"
  environment:
    POSTGRES_USER: ${DATABASE_USERNAME}
    POSTGRES_PASSWORD: ${DATABASE_PASSWORD}
  volumes:
    - ${YOUR_ORG_INSTALL_PATH}/volumes/services/postgres-data:/var/lib/postgresql/data:delegated

products-run-migrations:
  build:
    context: ./apps/products/migrations/.
  image: yourorg/products-run-migrations:${IMAGE_TAG:-latest}
  env_file:
    - ./apps/products/products.env
  depends_on:
    - postgres

products:
  build:
    context: ./apps/products/.
  image: yourorg/products:${IMAGE_TAG:-latest}
  env_file:
    - ./apps/products/products.env
  depends_on:
    - postgres
    - products-run-migrations

A few issues with this setup, focusing on depends_on:

The products-run-migrations script will run right when postgres starts to run, not when it's healthy and ready to accept connections. There is a 99% chance that the postgres container will not be healthy when the migrations begin to run, causing them to fail.
Similar situation with the products service, it will run right when products-run-migrations starts to run. If you query the products service when it's healthy, there is a good chance the migrations have not yet completed.

What We Want

This is currently not what we want, ideally developers should be able to start the products service and when it's healthy, know that the migrations ran successfully and they can query its API.

This required me to do some research.

I found out there is a conditions argument to depends_on I could use to achieve the implementation we wanted. But the next thing I found out is where things went haywire.

We needed to downgrade our docker-compose version.

Turns out, Docker Compose 3.x versions are meant to be used for Docker Swarm and Kubernetes environments where services are not strictly dependent on each other. This promotes a more fault-tolerant environment where services run independently.

What I saw people suggesting was to switch to Docker Compose 2.4 and use a port waiting script like wait-for-it.

Our new Docker Compose 2.4 file:

version: '2.4'

postgres:
  image: yourorg/postgres
  command: postgres -c 'max_connections=1024'
  expose:
    - '5432'
  environment:
    POSTGRES_USER: ${DATABASE_USERNAME}
    POSTGRES_PASSWORD: ${DATABASE_PASSWORD}
  volumes:
    - ${YOUR_ORG_INSTALL_PATH}/volumes/services/postgres-data:/var/lib/postgresql/data:delegated
  healthcheck:
    test: ['CMD-SHELL', 'pg_isready -U root']
    interval: 60s

products-run-migrations:
  build:
    context: ./apps/products/migrations/.
  image: yourorg/products-run-migrations:${IMAGE_TAG:-latest}
  entrypoint:
      - /bin/bash
      - -c
      - 'wait-for-it $$DATABASE_HOSTNAME:5432 -s -t 60 -- npm run db-migrate:products
  restart: on-failure:5
  env_file:
    - ./apps/products/products.env
  depends_on:
      postgres:
        condition: service_healthy

products:
  build:
    context: ./apps/products/.
  image: yourorg/products:${IMAGE_TAG:-latest}
  env_file:
    - ./apps/products/products.env
  restart: on-failure:5
  depends_on:
      postgres:
        condition: service_healthy
      products-run-migrations:
        condition: service_started

A few new additions:

Added a healthcheck to the postgres container. This made it so migration scripts like products-run-migrations can start to run only when the database is ready to accept connections.
We added an entrypoint along with the condition arg to depends_on to our migration images. This made sure that not only the database is running but that the port is returning a 200 response code.
Added condition args to both depends_on in the products service definition.

It's not perfect but works much better than before. The issue still remains of the app not waiting for the migrations to be fully finished before booting up. If they run relatively quickly, local developers may not run into problems. In CI, we have full control over the environment so we can add an extra command to skirt around this issue.

# .circleci/config.yml
test-products:
  executor: node-docker
  steps:
    - test-project:
        project-name: products
        pre-test-command: docker-compose run -T products-run-migrations
        tests:
          - run-project-test:
              project-name: products

The Issues That Still Remain

What I didn't touch on is what our production environment looks like in terms of Docker Compose. We decided to maintain two versions of our Docker Compose files, one in 2.4 and one in 3.7. This is because we want to adopt Kubernetes easily in the future. You may stick with one or the other but for a great local development experience, we decided to always have a 2.4 file going.

Build a Next.js Blog with Cosmic’s GraphQL API

Alec Brunelle — Wed, 23 Sep 2020 14:06:06 +0000

Want to follow along with the build? Click here to grab the app or fork the project.

With so many choices for which technology to use when building a website, it can get overwhelming. You need to consider who is going to use it, what content to display and who will maintain it. A static website is a great choice when creating a blog, band website or e-commerce store. Static websites are an ode to the past when websites were just plain-ol files on a server you accessed via URL. They provide benefits like being fast, having great SEO and not being dependent on a certain runtime like PHP. This is in comparison to a server-rendered website like what you would have with Wordpress, Drupal or Ruby on Rails.

Static websites are built using static assets. The next question becomes where to store (and manage) this content. If you are a solo webmaster, the content can be files in a Git repo. If you have clients or other developers who will want to manage the content, a CMS (Content Management System) is what you need. A CMS is a service which stores your website content, for example blog posts and concert dates.

Cosmic CMS!

With Next.js SSG, we are using the CMS in a "headless" fashion. After trying a bunch of Headless CMS offerings, one I've stuck with is Cosmic. Cosmic is an intuitive, powerful, and simple-to-use service which lets us get up and running quickly. They provide many starter apps that you can preview or fork. For example, I chose the Next.js Static Blog and had a production version of the website running in under 5 minutes.

Choosing the Tech

Next.js with GraphQL is my personal choice when it comes to Static site development. Next.js is a hybrid React framework which supports building static websites. It also lets you build server-side rendered pages when the need arises. It handles routing, has a large community supporting it making it one of the best ways to build a React app in 2020. The other tech you may have heard also does this is Gatsby.js. Gatsby is more user-friendly but is more opinionated with its technology choices (forced use of GraphQL versus it being a choice).

We are choosing to use GraphQL over the Cosmic NPM module. GraphQL is a standardized way to get data from services and is a great choice when needing to get data from a CMS. As you create custom data types in Cosmic, you are able to query for it in the GraphQL API. One of the benefits of using GraphQL is that you are less dependent on a specific SDK.

Tutorial

For reference, I forked the example Cosmic Next.js project here.

Creating the Cosmic Project

After creating an account on Cosmic and going through the product tour, you will be shown the “Create New Bucket” screen.

Click "Start with an App" then search and select "Next.js Static Blog" from the list of apps presented. This will do many of things.

Create a Cosmic bucket
Create sane data-types inside the bucket for use with a blog
Fill the bucket with demo content

Here is what the created bucket looks like on your Cosmic dashboard

Next.js local development

The next thing we need to do is clone the Next.js code to our local environments. This will enable us to run the Next.js locally and pull content from the demo Cosmic bucket we created.

git clone git@github.com:aleccool213/nextjs-cosmic-graphql-app.git

You can also choose to create a GitHub repository for yourself using the template.

Once inside the new directory, make sure you are using the correct Node.js version by using NVM.

nvm use v12.18.3

Install Yarn and install the project dependencies.

brew install yarn && yarn

Run the app!

yarn dev

Almost there!

Cosmic Environment Variables

Before we are able to query the Cosmic GraphQL API, our app needs to know where it lives. Environment Variables are deployment specific values which contain sensitive things like API keys.

There are three env vars we need to define to have the app work locally. Create a file named .env.local (don't worry it's ignored by Git), it should look like this:

COSMIC_BUCKET_SLUG=demo-nextjs-static-blog
COSMIC_READ_KEY=77H1zN7bTktdsgekxyB9FTpOrlVNE3KUP0UTptn5EqA7T0J8Qt
# Preview secret can be anything you choose
COSMIC_PREVIEW_SECRET=iwvrzpakhaavqbihwlrv

To get these values, head over to the Settings sidebar menu in your bucket, and click "Basic Settings".

Run the app again with yarn dev

And we are up!

Looking inside the box

There are two things that we need to understand when it comes to Statically-Generated Next.js apps, pages and routes. Pages are content which depend on external data, and routes are URL routes which depend on external data. Both have you defining special Next.js specific functions, getStaticProps and getStaticPaths.

The file which contains the logic for generating page content based on the Cosmic GraphQL API is located at pages/posts/[slug].js.

export async function getStaticProps({ params, preview = null }) {
  // Get the data from the API
  const data = await getPostAndMorePosts(params.slug, preview);
  // Convert markdown content to HTML content
  const content = await markdownToHtml(data.post?.metadata?.content || "");
  return {
    props: {
      preview,
      post: {
        ...data.post,
        content,
      },
      morePosts: data.morePosts || [],
    },
  };
}

export async function getPostAndMorePosts(slug, preview) {
  // Query for the data through the Cosmic GraphQL API using Apollo Client
  ...
  const moreObjectsResults = await client.query({
    query: gql`
      query getPostQuery(
        $bucketSlug: String!
        $readKey: String!
        $status: status
      ) {
        getObjects(
          bucket_slug: $bucketSlug
          input: {
            read_key: $readKey
            type: "posts"
            status: $status
            limit: 3
          }
        ) {
          objects {
            _id
            slug
            title
            metadata
            created_at
          }
        }
      }
    `,
    variables: {
      bucketSlug: BUCKET_SLUG,
      readKey: READ_KEY,
      status,
    },
  });

This is one example of a page using getStaticProps. It is also used in the Index page for getting all the blog post titles and excerpts.

pages/posts/[slug].js also contains getStaticPaths which tells our Next.js app which routes to generate.

export async function getStaticPaths() {
  // Get all post data (including content)
  const allPosts = (await getAllPostsWithSlug()) || [];
  return {
    // Tell Next.js all of the potential URL routes based on slugs
    paths: allPosts.map((post) => `/posts/${post.slug}`),
    fallback: true,
  };
}

After understanding these two aspects, the blog is just a regular React app.

Deploying

Now that we have our website working locally, let's deploy it to Vercel. The first step is making sure you have the code in a Git repository.

I recommend you have the code in GitHub. You can use the GitHub CLI to create a repo in your current directory with gh repo create.

We now need to sign up for Vercel and have it use the code from the GitHub repo. You can sign up for Vercel with your GitHub account here. You can import the code from GitHub using the "Import Project" feature.

When importing the project, make sure you define the environment variables, COSMIC_BUCKET_SLUG, COSMIC_READ_KEY, and COSMIC_PREVIEW_SECRET.

When deployed, all pushes to your default Git branch will have Vercel deploy a new version of your website!

Bonus

Previewing

The Next.js docs on preview mode are right here.

Local development and deploying the website to production will cover most of your use-cases. Another common workflow is saving a draft of changes on your CMS and then previewing those changes on your local machine. To do so, we will enable "Preview" mode both on Cosmic and our Next.js app.

First thing we will need to do is have Cosmic know that the Posts object type will be preview-able. On the Posts setting page, add the preview link.

http://localhost:3000/api/preview?secret=iwvrzpakhaavqbihwlrv&slug=[object_slug]

When finished, click "Save Object Type".

Let's try editing a post and see it show up on our local machine. Try changing the title of "Learn How to Pre-render Pages Using Static Generation with Next.js" and click "Save Draft" instead of "Publish".

The Save Draft button

We now have unpublished changes. Run the app locally with yarn dev and then click "Preview" right under "Save Draft".

Our preview mode!

Webhooks

Note this feature requires a Cosmic paid plan

The only way to deploy new content to our blog is to have a developer push to the default git branch. This action will trigger Vercel take the new code and push a new version of our website. We ideally want our content creators to have the same control. Webhooks are a way we can do this.

Let's set up a webhook which lets Vercel know when our posts in Cosmic have new updates. This will let us deploy new versions of the website without developers needing to do anything.

Go to the Git integration settings page (https://vercel.com/[project]/settings/git-integration) in your Vercel project and create a new Deploy Hook named "Cosmic Hook".

What your settings should look like when the webhook is created

Now over in Cosmic settings, we can add this webhook. Let's add Cosmic notify Vercel when changes get published. You can see how we can do this for previews as well if we wanted to in the future.

Edited/Created and Published!

To test this go to the same post we tested Previews with and add some content to the end of the article and publish. You should see a deploy happen on Vercel with the new content deployed to the live version of your website!

Conclusion

Want to see what the final website looks like? Click here to check it out.

Like this post? Subscribe to my email newsletter for more like it in the future.

Calm, Private and Healthy, A HEY Email Review

Alec Brunelle — Wed, 29 Jul 2020 12:41:57 +0000

Want more great content like this? Sign up for my newsletter, visit: alec.coffee/signup

You might have seen Basecamp making headlines when they took on Apple to fight for fair app-store monetization policies. HEY is a new email service which, you guessed it, sends and receives email. Going up against competitors with huge head starts, HEY sets out to change the flavour of email as opposed to adding a little spice. After trying it for two weeks, HEY made my email experience a more calm, private and healthy experience with little to complain about.

HEY targets those who are tired with existing solutions, the users who see email as a chore and not what it should be, a delightful, curated experience. HEY gives you complete control over where email should go, who is allowed to give you a push notification and so on. Shifting away from automated filters and into a more controlling experience is tough at first but is worth it in the end.

I switched from Gmail to Fastmail years ago for simplicity and enhanced privacy. There is something to be said about spending money on a small business versus one which cares about its ad revenue more than it's users that lures me to a service. HEY is a big step forward in the same direction as Fastmail.

Email Hygiene

Basecamp is looking at email from the ground up. Jason Fried, founder and CEO of Basecamp, says it well in his walk-through of the product:

One of the problems with email is that everybody can email you, which is also one of the great things about email

I see myself as a hygienic email user, using filters and labels as much as I can, and try my best to combat the fact that anyone has access to my inbox. A few custom rules to put emails to certain folders, rules to make my inbox feel a more clear and less cluttered. For example, I have a newsletter rule where emails I don't care about go (sorry to the marketers who are reading this) and a rule for receipts. This happened to map 1-1 with HEY's "The Feed" and "The Paper Trail". This meant that using HEY was already familiar to me. It made my workflow for creating rules much easier with "The Screener" which buckets sender's into these categories with unmatched speed. I can say that these buckets were enough. Non-categorized senders turned out to be important and kept going into my "Imbox". If they abused the fact they had this access, I would screen them out, banished to the shadow-realm, my spam folder.

When all the filters are at full steam, checking email is a calming and less stressful experience. This is something I never thought email would make me feel. Another reason for this is that no notifications are sent to you for new emails by default, you need to choose who is able to notify you. This falls in line with how much control HEY gives you, it lets you decide what is important.

The Imbox

Ultimate privacy

Okay, get this, every email that you receive has a tracker inside it, it can tell when you opened it, where you opened it and how many times you opened it. Well, not every single one, but every email you get might have it because you wouldn't be able to tell the difference. Senders put a 1x1 HTML image element inside an email (hidden from view), when you open it this image gets loaded from the sender's server. This is how a bunch of information like I described earlier is then sent back to the email sender. Blocking this behaviour is as easy as not loading images when you open an email, which no email client does by default, it needs to be set by the user. The other problem is that if you turn that on, you can hardly read emails because usually, the content depends on images loading. HEY brings a feature that surprises me no one else is doing yet, filtering out those pixel trackers.

Filtering out pixel trackers is akin to a DNS server that has ad-blocking enabled. I already use one of these called NextDNS. It works well and makes it so I don't have to do ad-blocking client-side, for example with a browser extension. How HEY does this is that it loads images within your email on a server within their network. This makes the sender think the email has been opened by you (but it was opened by HEY). HEY then shows you these pre-loaded images from their server, along with the email it was placed in. Being the privacy-oriented person I am the price tag for HEY may be worth it just for this.

The horror, vendor lock-in

To do this magic, Basecamp decided to not let users integrate using email protocols such as IMAP, POP3 and SMTP. This means you can't use HEY with any other client than their own. Mail for MacOS, Thunderbird, yup, all out of the question. This is a con of the service, other email clients have been in development for eons and come with useful features, too many to mention here. HEY comes with native apps for every device you use but it stills feels wrong to not talk about it. I get it why they don't want to support it, most of HEY's features wouldn't make sense on a traditional email client. For example, screening senders, merging/renaming threads, and others.

If you decide to switch off of HEY, exporting all your emails is possible so you don't have to worry about your history being lost. HEY promises to forward your emails sent to your old HEY address to a new address if you do decide to switch (that is if you paid for HEY in the first place).

Yet another thing to "learn"

The problem with new software products is that the learning curve usually is steep. New product fatigue is hard to deal with and this is why new products that come out try to steal features from existing solutions for easy adoption. HEY suffers from this, you will need to learn how to use it or you will get lost and won't feel comfortable switching. An on-boarding experience and tutorials covering HEY's features help but I felt like these need improvement. I felt sad when the tutorials stopped coming, I wasn't comfortable to navigate my email alone yet. Nuances like moving emails around to different folders and not knowing if future emails will go there. Little things to criticize but shouldn't stop anyone from enjoying what Basecamp has built.

Conclusion

Getting to this point took some strong-willed people willing to take a risk, going up against established players in the game. HEY isn't a perfect email app but it pushes the boundaries of how email should work. This alone is commendable, most companies don't have the gusto to do this. I decided not to pay for a full-year sub as they don't support custom domains and switching email addresses was painful the last time I did. I only have the energy, time and motivation to do this once a decade. They have a form to stay up to date and get notified when this feature ships as they know it's the reason a lot of people are waiting to pay.

A Better Way to use GraphQL Fragments in React

Alec Brunelle — Tue, 12 May 2020 13:27:39 +0000

Want more great content like this? Sign up for my newsletter, visit: alec.coffee/signup

One of the great reasons to use a component-based framework (React, Vue) is that it allows for more isolated component design, which helps with decoupling and unit-testing. Another benefit is using showcase apps such as Storybook, these continue the philosophy of isolation and allow for design and prototyping outside the main application. When component count starts to grow and we start to fetch data, we need a new pattern, the Container Component pattern. If using GraphQL for your data transport, we want to keep using this pattern but with a new twist. When creating isolated components, they should define the data they need to render. This can be better achieved by each component, even presentational ones, defining the data they need to render with their own GraphQL fragment.

Show Time

Let's say we have a component which renders a list of Github issues showing their title. In the Container Component pattern, we would have a "container" component, GithubIssueListContainer, which handles running the query. After this, it passes down the data to its presentational components which need it to render, GithubIssueInfoCard.

const GITHUB_ISSUES_LIST_QUERY = gql`
  query GithubIssuesListContainerQuery {
    organization {
      id
      name
    }
    issues {
    totalCount
    pageInfo {
      endCursor
      hasNextPage
    }
    edges {
      node {
        id
        title
        description
      }
    }
  }
`;

const GithubIssueListContainer = () => {
  const { loading, error, data } = useQuery(GITHUB_ISSUES_LIST_QUERY);
  return (
    {data.issues.edges.map(
      edge =>
      (
        <span key={edge.node.id}>
          <GithubIssueInfoCard issueDetails={edge.node} />
        </span>
      ),
    )}
  );
}

interface GithubIssueInfoCardProps {
  issueDetails: {
    id: string;
    title: string;
    description: string;
  }
}

const GithubIssueInfoCard = ({ issueDetails }) => {
  return (
    <>
      {issueDetails.id} {issueDetails.title} {issueDetails.description}
    </>
  )
}

The issue here is that GithubIssueInfoCard is dependent on its parent component in its knowledge of where data comes from in the GraphQL graph.

If we want to render a new field from the graph, e.g. labels, we will need to add that to the query in GithubIssueListContainer and pass that down to GithubIssueInfoCard via props. This requires changes to the both the query in GithubIssueListContainer and the props in GithubIssueInfoCard.

This is the Way

Following along our mantra of isolation, how about if GithubIssueInfoCard defined what data it needs to render from the GraphQL graph. That way, when we make changes to what data this component, only this component needs to change.

const GITHUB_ISSUES_LIST_QUERY = gql`
  ${GITHUB_ISSUE_INFO_CARD_FRAGMENT}
  query GithubIssuesListContainerQuery {
    organization {
      id
      name
    }
    issues {
      totalCount
      pageInfo {
        endCursor
        hasNextPage
      }
      edges {
        node {
          ...GithubIssueInfoCardFragment
        }
      }
    }
  }
`;

const GithubIssueListContainer = () => {
  const { data } = useQuery(GITHUB_ISSUES_LIST_QUERY);
  return (
    {data.issues.edges.map(
      edge =>
      (
        <span key={edge.node.id}>
          <GithubIssueInfoCard issueDetails={edge.node} />
        </span>
      ),
    )}
  );
}

export const GITHUB_ISSUE_INFO_CARD_FRAGMENT = gql`
  fragment GithubIssueInfoCardFragment on Issue {
    id
    title
    description
  }
`;

interface GithubIssueInfoCardProps {
  issueDetails: {
    id: string;
    title: string;
    description: string;
  }
}

const GithubIssueInfoCard = ({ issueDetails }) => {
  return (
    <>
      {issueDetails.id} {issueDetails.title} {issueDetails.description}
    </>
  )
}

This might seem odd at first, but the benefits are worth it. As with anything in programming it doesn't come without tradeoffs.

Benefits

Less parent component coupling

When components define the data it needs to render, it de-couples the component from its parent. If for example you wanted to show GithubIssueInfoCard on another page, import the fragment into that container component to get the right data fetched. e.g.

import {
  GITHUB_ISSUE_INFO_CARD_FRAGMENT,
  GithubIssueInfoCard,
} from "./GithubIssueInfoCard";

const NOTIFICATIONS_LIST_QUERY = gql`
  ${GITHUB_ISSUE_INFO_CARD_FRAGMENT}
  query NotificationsContainerQuery {
    notifications {
      totalCount
      pageInfo {
        endCursor
        hasNextPage
      }
      edges {
        node {
          id
          eventText
          eventAssignee {
            id
            avatar
            username
          }
          relatedIssue {
            ...GithubIssueInfoCardFragment
          }
        }
      }
    }
  }
`;

Types become easier to maintain

If using a TypeScript, you likely are generating types from your GraphQL queries. A large benefit of our new pattern comes with defining props in components. You can define the data it needs to render as a type from our generated type file.

import { GithubIssueInfoCardFragment } from "../../graphql-types";

interface GithubIssueInfoCardProps {
  issueDetails: GithubIssueInfoCardFragment;
}

When the fragment changes, after you generate types, no prop changes needed!

Less chance of changes when developing component first

With Storybook becoming popular, many developers are starting to develop components in Storybook first and the integrating them into the app at a later time. What may happen is that in app integration, props are defined incorrectly.

Defining the fragment of the GraphQL graph this component needs to render, there are less chances of code changes when integration happens due to forcing the developer to know the exact shape of the data it needs to render. This of course is only possible defining the api in advance which sometimes isn't always the case.

Trade-offs

Of course, like everything in programming, there are trade-offs in this approach. It's up to you to see if it's worth it.

Presentational components are not generic

The crummy thing is that our presentational components become more coupled to the application and API data model. If we want to migrate over to a component library for others to use, these components will need to be refactored to have their fragments removed. It's not too much work, but it is more work than the alternative.

Fragments sometimes become difficult to manage

Importing many fragments into a single GraphQL query isn't the best experience. If we have many presentational components within a container component, importing them all can be hairy. Sometimes you may forget to import the fragment and Apollo can return some unhelpful messages.

const GITHUB_ISSUES_LIST_QUERY = gql`
  ${GITHUB_ORG_INFO_CARD_FRAGMENT}
  ${GITHUB_ISSUE_COUNT_CARD_FRAGMENT}
  ${GITHUB_ISSUE_INFO_CARD_FRAGMENT}
  query GithubIssuesListContainerQuery {
    ...GithubOrgInfoCardFragment
    issues {
      ...GithubIssueCountCardFragment
      pageInfo {
        endCursor
        hasNextPage
      }
      edges {
        node {
          ...GithubIssueInfoCardFragment
        }
      }
    }
  }
`;

Conclusion

We have been using this pattern at Yolk for a while now and it has grown on everyone. We develop our components first in Storybook and it forces the developer to understand where the data is coming from and ask questions about the data model and it's usage.

How does your company handle research and investigation work?

Alec Brunelle — Sat, 25 Apr 2020 14:45:42 +0000

Software companies which follow agile usually do some sort of planning and estimation. It lets stakeholders know how long things will take to get done and can help with how a project plays out. To get better estimations, developers are usually tasked with doing some initial research to find out how difficult things will be, what unknowns exist.

How does your component do this from a process standpoint? Tickets? Spikes (a form of research ticket familiar to some)? Nothing at all?

Publishing a JavaScript Package to NPM automatically with Github Actions

Alec Brunelle — Wed, 25 Mar 2020 15:03:03 +0000

Want more great content like this? Sign up for my newsletter, visit: alec.coffee/signup

Maintaining an open-source package can be a time-consuming task. Issues to be triaged, pull requests to be reviewed and changelogs to write. Publishing new versions of the code is usually done manually and making it automated is often on the back-burner of the maintainers' to-do list. There are a couple of key features of a rock-solid release process, the changelog, Git tags, NPM versions, and enforcing Semantic Versioning. Keeping all these in sync makes it so users understand changes in a release and understand how to keep up-to-date. Maintainers who fail to perform all of these steps will have a hard time triaging issues, which leads to more time debugging and less time spent coding. I recently came across a combo of tools, semantic-release and Github Actions, which made the entire release process automated, transparent, and simple to understand.

semantic-release / semantic-release

📦🚀 Fully automated version management and package publishing

📦🚀 semantic-release

Fully automated version management and package publishing

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification and communicating the impact of changes to consumers.

Trust us, this will change your workflow for the better. – egghead.io

Highlights

Fully automated release
Enforce Semantic Versioning specification
New features and fixes are immediately available to users
Notify maintainers and users of new releases
Use formalized commit message convention to document changes in the codebase
Publish on different distribution channels (such as npm dist-tags) based on git merges
Integrate with your continuous integration workflow
Avoid potential errors associated with manual releases
Support any package managers and languages via plugins
Simple and reusable configuration via shareable configurations

How does it work?

Commit

…

View on GitHub

How It Works

Before we talk about implementation, it's important to understand what work our tools will perform. That way, if there are problems or modifications, we can fix them. semantic-release is going to do the majority of the work here, they say it best on their README.

It automates the whole package release workflow including determining the next version number, generating the release notes and publishing the package.

The Next Version Number

During a release, to determine the next version number, the tool reads commits since the last release. It knows your last release by looking at your Git tags. Based on the type of commit, it can determine how to bump up the version of the package. For this to work, commits need to be written in a certain way. By default, semantic-release uses the Angular Commit Message Conventions. This is critical because consumers of the package need to know if a new version releases a new feature, introduces breaking changes or both. For example, if someone commits fix(pencil): stop graphite breaking when too much pressure applied, semantic-release knows this contains a fix and to create a patch release. This will increase the version in the minor version range (0.0.x).

Never seen this type of versioning before? Check out Semantic Versioning.

After analyzing all the commits, it takes the highest priority type of change and makes sure that is the one that is applied. For example, if two commits were introduced since the last release, one breaking (x.0.0) and one minor (0.0.x), it would know to just up the version by breaking range.

Generating Release Notes

Once it has done finding out what type of release the next version is, changelog notes are generated based on the commits. semantic-release doesn't use conventional CHANGELOG.md file to notify users of what has changed, it does so with a Github Release which is attached to a Git tag.

An example of a Github Release that semantic-release generates and pushes on builds.

Automating With Github Actions

So semantic-release will be the tool to perform most of the work, but we still need a service to run the tool on. That is where Github Actions comes into play. When pull-requests are merged into master (or any base branch you configure), Github Actions will run a job that simply runs semantic-release with your configuration. All of the work we described previously will be performed.

An example of a Github Actions run using semantic-release to publish a new release.

Steps to Take

We will be using as many defaults as possible to make configuration dead simple. semantic-release uses a plugins system to enhance functionality. Here are the default plugins semantic-release uses.

Let's go over the steps which will make this all run smoothly.

Add a dummy version property to the package.json of package. Released code will have the proper version written to this file by semantic-release.

        "version": "0.0.0-development",

Add a new property to the package.json, publishConfig. This will be the home of our semantic-release configuration.

        "publishConfig": { "access": "public", "branches": ['master'] }

The last step is to create a Github Action YAML file. This will tell Github Actions what to do when a commit is made to the repository.

        # .github/workflows/test-and-release.yaml

        name: Test and Release
        on: [push]

        jobs:
        test-and-release:
            name: Run tests and release
            runs-on: ubuntu-18.04
            steps:
            - name: Checkout
                uses: actions/checkout@v1
            - name: Setup Node.js
                uses: actions/setup-node@v1
                with:
                node-version: 12
            - name: Install dependencies
                run: npm ci
            - name: Run tests
                run: npm test
            - name: Release
                env:
                GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
                NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
                run: npm run semantic-release

Add NPM_TOKEN to the secrets in the Github repos settings page. You can generate one of these from your NPM account at https://www.npmjs.com/settings//tokens

And that's it! You have a fully automated package release process 🎉

Bonus

I implemented this on a repo we recently open-sourced at Yolk AI. It's named next-utils and everything described here can be found there.

Yolk-HQ / next-utils

🥩 🍳 A set of Next.js HoC utilities to make your life easier

next-utils

A set of Next.js utilities to make your life easier.

ATTENTION: This project is no longer maintained.

Overview

React Higher-Order Components for use with Next.js, enabling simple, server-side-render-compatible configuration of functionality such as:

Installation

This module is distributed via npm which is bundled with node and should be installed as one of your project's dependencies:

npm install @yolkai/next-utils

Note

NOTE: Using any of these Higher-Order-Components will disable Automatic Static Optimization (statically built pages), since the Higher-Order-Component forces every page to implement getInitialProps.

🔮 Apollo Client

appWithApolloClient

Example Usage

Code

React higher-order component (HoC) which wraps the App component and:

Performs the page's initial GraphQL request on the server, and serializes the result to be used as the initial Apollo state once the client…

View on GitHub

Another great thing about using semantic-release with Github Actions is that it has out-of-the-box support for bot comments. It will go into every issue and pull-request closed since the last release and comment to make sure everyone is aware. Here is an example:

Comment for #12

github-actions[bot] commented on Feb 03, 2020

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

View on GitHub

If you liked this post, check out more at https://blog.alec.coffee and signup for my newsletter

Quit Google Analytics, Self-hosted Gatsby Statistics with Ackee

Alec Brunelle — Wed, 12 Feb 2020 20:26:27 +0000

Want more great content like this? Sign up for my newsletter, visit: alec.coffee/signup

There are many different goals one can have when it comes to hosting your own website or blog. For myself, it means just having a place where I own the content of my words and can customize it to my liking. When it comes to analytics, my needs aren’t many, as most of my audience reads my content via platforms like dev.to or Medium. All I need to know is how many people visit my site, which posts are doing well and where users come from (referral links). Given my recent obsessive elimination of all things tracking and advertising in my life, I chose to stop supporting Google and move from Google Analytics to something self-hosted. It wasn't an easy product to use and most of the features were useless to me as I don't sell anything on my blog. This way I own the data and am not contributing it to a company that could use it in potentially malicious ways.

I set out to search for a new tracking tool for my blog. My criteria for choosing a new product were:

Be simple
Have features I will use
Put a focus on privacy
Built with a programming language I know so making changes is easy
Be able to easily host on a Platform-as-a-Service like Heroku
Have the ability to be easily added to a Gatsby blog
Have an option to not collect unique user data such as OS, Browser Info, Device & ScreenSize

Meet Ackee

Beautiful, isn't it

I came across Ackee 🔮, a self-hosted analytics tool. This tool fit my requirements almost perfectly. It is built using Node.js which I have experience in and it focuses on anonymizing data that it collects. More information on how Ackee anonymizes data here.

The steps you need to take to start collecting statistics with Ackee are to start running it on a server, Heroku in my case, add the Javascript tracker to your Gatsby site and test to see if the data is flowing correctly.

This a detailed guide on how I went about deploying it to Heroku. Afterwards, I contributed back a Deploy-to-Heroku button which deploys it in one-click. Find the button here.

Up and running on Heroku

First thing is to start running the server which is going to receive the tracking data from your website.

Create a new Heroku app instance

Use the heroku-cli to upload the code

# clone the code
git clone git@github.com:electerious/Ackee.git

# login to heroku
heroku login

# add the heroku remote
heroku git:remote -a ackee-server

# push the code
git push heroku master

Configure a MongoDB add-on, this is where the data will be stored

Configure the environment variables

heroku config:set ACKEE_PASSWORD=<your password>
heroku config:set ACKEE_USERNAME=<your username>

And voila! You are finished, that was easy, wasn't it? Open the webpage Heroku automatically configures for you, it should be https://ackee-server.herokuapp.com/, you should see this:

The log in page!

Adding the tracker

Now we need to send data over from the website to the server we now have running on Heroku. If you are using Gatsby, this is incredibly easy with the plugin.

Install the tracker

npm install gatsby-plugin-ackee-tracker

Create a domain on Ackee and get the domain id. Find this option in the settings tab of your Ackee instance.
Add it to your Gatsby config

{
    resolve: "gatsby-plugin-ackee-tracker",
    options: {
        // Domain ID found when adding a domain in the admin panel.
        domainId: "<your domain id>",
        // URL to Server eg: "https://analytics.test.com".
        server: "https://ackee-server.herokuapp.com",
        // Disabled analytic tracking when running locally
        // IMPORTANT: Set this back to false when you are done testing
        ignoreLocalhost: true,
        // If enabled it will collect info on OS, BrowserInfo, Device  & ScreenSize
        // False due to detailed information being personalized:
        // https://github.com/electerious/Ackee/blob/master/docs/Anonymization.md#personal-data
        detailed: false
    }
},

Run the site locally
```
gatsby develop
```

Testing to make sure it worked

Open up your site at http://localhost:8000 and go to a new url.

Observe the network requests your site is sending. You will notice it now sends requests to your Heroku instance.

Using the dev tools

And with that, we now have the server running Ackee and our Gatsby sending analytics!

What you get

Let’s explore Ackee, shall we.

Home page with total site views

List of referrers

Per page view count

Alternatives

Here are some alternative methods I considered when thinking about analytics for my blog.

No tracking

Combined with the fact more and more people are blocking trackers all-together (Firefox, Brave and Chrome ad blocking extensions), JavaScript-based tracking is becoming less and less valuable over-time. Most analytics can easily become a way to be vain about your blog and you can start a bad habit of always checking them (wasted time compared to producing actual content). Deciding not to track any analytics at all is not a bad decision these days.

Server-side analytics

The most private and fast way of collecting analytics on your website may be to collect analytics at the server level. What this means is instead of using a JavaScript tracker (which may be blocked by the browser), stats are collected when the HTML is sent from the server. Integration with your static host provider or DNS provider is needed here. The main con about this method is that data is collected by a third party service and also is usually not free. Cloudflare offers these types of analytics alongside Netlify. A huge benefit is the ease of setup, usually the provider just turns it on with a switch on their side, no setup needed from you.

Is knowing how to use Docker a prerequisite to becoming a Senior Software Developer?

Alec Brunelle — Wed, 22 Jan 2020 21:12:52 +0000

Just a question I think needs some discussion. I know titles in software dev are pretty much out the window at this point, but was curious on the communities thoughts.

Is knowing what containers are and how to use them necessary in 2020? Docker specifically?

1 year with Cypress: The Guide to End-To-End Testing 🚀

Alec Brunelle — Fri, 20 Dec 2019 13:35:11 +0000

Want more great content like this? Sign up for my newsletter, visit: alec.coffee/signup

Like this post? Checkout my other posts on dev.to, or consider buying me a coffee to support me writing more.

In software development, the faster you move, the more things break. As a codebase grows larger and larger, its pieces become more and more complex, every line adding a potential bug. The best organizations keep a handle on this through rigorous amounts of testing. Manual testing requires a lot of effort, that's where automated testing comes in. One of the hot frameworks on the scene is Cypress, a complete end-to-end testing solution.

In the past, web-app end-to-end testing has been a tricky beast. Selenium has been the main solution for quite some time and has a huge history. It has great browser compatibility but having your tests be consistent is difficult because it wasn't designed for app testing. That's why I got so excited when I heard about Cypress, promising to fix all of the old and broken ways of past frameworks. After writing and reviewing close to 200 test scenarios in the past year (that's with a small team), I wanted to write about what I wish I knew when I started and share my thoughts on my journey with Cypress thus far.

What's in the box

So many features packed in 😃

End-to-end testing has always been a fragmented experience. You need to bring a lot of your own tools, for example, a test runner, an assertion library, and maybe other things like mocks. With Cypress, it packages all of those things together, this makes set up and configuration, dead simple. Not only that, the documentation is some of the best I have ever read in my career, with guides on everything you are likely to encounter. Not only do they do a great job telling you how to use the product, but have in-depth explanations on the architecture, flakey tests and best practices.

Prototyping

If you have the chance, before adopting anything of this scale, I always think it's a good idea to test it on a small project first, just to get a feel. Before advocating for it, I added it to my personal blog, just to see how the experience was.

A very simple scenario:

Load up the app
Go to the index page
Click the first blog post link
Assert content shows up

I was blown away with how fast it took me, under an hour. This was really as simple as writing a few lines of Javascript for the test itself, the npm script in the package.json, and running it in CircleCI. Not only did Cypress perform the assertions but also it was recording videos! This could have been an even faster setup if I used the CircleCi Cypress Orb.

This got me a huge amount of test coverage in very little time. This proof of concept was more than enough to convince my team that Cypress was the right choice when it came time to start writing end-to-end automated tests.

Decisions and Tradeoffs

The browser-based products we have at Yolk are completely separated from the server-side API's they fetch data from, they build and are served separately. This presents a few ways forward when deciding to write end-to-end tests. You can either deploy your backend with your frontend and test as if the app is in production or completely mock out API responses. Using a real backend means spinning up potentially memory-intensive processes when running on CI but you get the assurance that apps are near-production. With mocking your API responses, you test less of your stack, risk stubbing out non-realistic responses, and have to worry about the extra maintenance of keeping them up-to-date.

We decided on deploying live instances of the backends related to the app we were testing. This decision was easy for us to make due to already having a CLI tool to do much of the hard work. This tool (aptly named yolk-cli) downloads the latest docker images for apps and knows how to spin up products with minimal configuration. This made getting the real APIs working on CI not too huge of a task.

Turns out, running two or three large python apps and a few Next.js servers on CircleCI does crap out the memory limit pretty fast. We reached out to CircleCI and they gave us access to their large resource classes (up to 16gb of RAM), score!

Seeding Data

The next challenge we faced was seeding data. Your test scenarios must share as little state as possible with each other. This is a testing fundamental and Cypress addresses it in their guides. Having test scenarios data-independent goes a long way when debugging why things are going wrong. On the flip side, having all of your data be created through the UI will make for slow tests, there is a balance. This will be highly customized to how your app works but I will go into what worked for us.

Going back to our cli tool once again, it had a few commands which seeded some basic data. The commands looked like this:

yolk seed-articles

yolk seed-bots

Getting your feet off the ground with data that is basic to your app, static data or very high-level entities, for example, will speed up this process and will be easy to run on each CI build.

The next part will be seeding data for entities that may be more specific to individual tests. This is where things get contested, there is no silver bullet for this. We decided to call the APIs directly for these situations and use Cypress custom commands to initiate these requests. This was a decent choice because we are using GraphQL; the custom commands that use the API were easy to write and document.

Writing custom commands for actions which your tests will be performing over and over are a great way to consolidate all code, not just data seeders!

Writing Scenarios with Gherkin

If you have written end-to-end tests before, you may be familiar with Gherkin syntax, used by Cucumber. This is an expressive, English-like way to write test scenarios. It can help with documenting your features and non-developers can contribute to writing test cases. We found a way to integrate this file syntax into Cypress using a plugin.

After writing these commands, the plugin will then go to Cypress to actually run the implementations:

Asserting Elements and Best Practices

When it comes down to it, end-to-end testing is just making sure elements on the page have the correct content. When writing Cypress tests, 90% of the time you will need to be selecting elements and peering inside them. Cypress has a standard get() command which exposes a JQuery-like selector to you, this should be familiar to those who have worked with Selenium. The problem with this selector is that it can be used incorrectly and you can't enforce (with code) it's usage. Welcome cypress-testing-library, a wonderful tool maintained by a great testing advocate in the community, Kent C. Dodds.

This plugin exposes a myriad of commands prefixed with find which work similarly to how get() does in native Cypress. All of these commands make for selectors that are resilient to change. This can have a dramatic effect on how your tests stay consistent as your application progresses.

Debugging

If you have ever worked with Selenium before, you know that debugging end-to-end tests can be somewhat of a nightmare. With Cypress, this pain is at an all-time low. Being a focus of the core product, being able to debug is one of the more pleasant experiences in your Cypress journey. Like for most things, they have a great guide to get you started.

Most of the things they have mentioned are great but the case which you will likely run into the most is a selector being incorrect. For this type of scenario, the GUI is a great way to find out what is going wrong. There is a nice video explaining how to write your first test and it shows the GUI in action.

Visual Testing and Catching Regressions

Another critical part of end-to-end testing will be how things look. HTML and CSS play a huge part in how your application will look like in different scenarios. Cypress can give you a lot of coverage in terms of how your app works but starts to break down when you want to assert its looks. Especially when it comes to browser compatibility and the different screen sizes your application is used in, visual regressions are hard to catch without proper implementation of Visual Snapshot Testing.

The solution we ended up with was Percy as it integrates nicely with Cypress and Storybook. What it can do is take the current HTML and CSS which is being rendered in your Cypress test scenario and send it over to Percy's servers. Percy then renders the markup on its own internal browsers, with Chrome and Firefox being options. Percy knows which feature branch your Cypress test is being run in and compares this with your configured base branch. This can give you great confidence in pull requests when you don't know if code is changing the look of a certain component in your application. This can be a big time-saver if you have a lot of code in your Cypress tests that assert css values or how things should look.

Hot Tip: You can have Cypress take snapshots locally and then with Percy only when it's enabled by creating a new takeSnapshot custom command:

Parallel Builds and the Cypress Dashboard

Once test runs start to become long enough, you will start looking for other strategies to speed them up. Parallelization is something that can be performed due to Cypress running feature scenario files with a clean state each time they are run. You can decide on your own balance strategy, how your tests can be broken up, but the hosted version of Cypress Dashboard provides a way to do this automatically.

Let's say I can afford to have three CircleCI containers to run my Cypress tests. First, I define the parallelism: 3 in my CircleCI job step config. What this will do is spin up three instances of your job, all with different job ids. Pass those ids off to Cypress, and you are off to the races. If you have Cypress Dashboard set up correctly, that service will tell your container which tests it should run. Here is an example of the config:

The super neat thing about this is that Cypress Dashboard knows your past test history and their speeds. It will use this knowledge to optimize your parallel builds by making sure the containers get a balanced load of tests to run!

Don't worry if this doesn't make much sense to you, Cypress has answered how to do this.

Browser Support

Unfortunately, if your organization needs to have support for IE11, you are out of luck. The Cypress team has explicitly said they won't be supporting it. There is an incredible thread on Github that I really hope you read through. It goes into why they are rolling this out slowly and didn't choose WebDriver from the beginning and wrote their own custom driver.

For us at Yolk, we needed IE11 support for a couple of our applications. We kept getting regressions within IE11 and needed more comprehensive test coverage. We decided to use Browserstack Automate and Selenium to cover these apps. For CI, we already had the app built and running in Cypress, we just needed to add a new build step that ran these tests using the Browserstack Local Proxy.

For the tests themselves, we decided to integrate Selenium with Cucumber, a common pairing. To make this process easier, we copied our Gherkin .feature files over to a new folder and wrote specific Selenium-based step implementations.

A cool concept I had an idea for was to re-use the same .feature files across both Cypress and Selenium. If anyone has ideas on this, please comment below with your suggestion 😃

It depends on how far you take this strategy and to decide if having duplicate test coverage is worth it to you. For us, having at least happy-path end-to-end test coverage in I.E.11 gave us a huge amount of confidence when deploying so the cost was worth it. In my opinion, it isn't as bad as it seems, our Cypress tests cover Chromium-based browsers (with Firefox support coming soon) and our Selenium tests cover I.E.11. With I.E.11 being phased out more and more, even in the enterprise, the need for Selenium will go away and the need for Cypress will get even larger.

Bonus: Typescript Support and Code Coverage

All of the libraries and modules I have mentioned previously come with Typescript support. Getting Typescript to work with Cypress doesn't require many configs and is totally worth it in the long run. All you will need are Webpack, TS config, plugin files which integrate with Cypress. A good guide provided by Cypress is here.

I know a lot of people wonder about code coverage and generating reports, Cypress can do that as well! Again, there is a nice plugin that lets you do it. The one caveat is that it will attach coverage counters to your code so running your tests will be slower and may not mimic production. A good strategy here is to just generate them locally once in a while to see how you are doing.

If your backend and frontend are in Typescript, a cool idea is having code coverage running in both apps when Cypress runs. You can then see the coverage across your entire app!

My first meetup talk @ GraphQL Toronto ⚛️

Alec Brunelle — Thu, 05 Dec 2019 23:23:39 +0000

Not me pictured lol

The one skill I think every developer should practice is public speaking. Unless you are a remote-developer who doesn't do audio OR video calls (idk if this exists), every developer needs to communicate ideas, thoughts, and plans with other co-workers.

I am pretty committed to this idea so I did a couple of talks last year just to my coworkers. This got me much needed practice and gave the chance for people to give me feedback.

Anyways, I decided that once a year is a good cadence for giving talks and meetups are the next stepping stone for me. I reached out to Paul Dowman at Shopify who was running the next GraphQL Toronto meetup. He accepted my offer to do a talk on Apollo Local State and the rest is history 😇

The slides

Blog post I wrote on the subject

A lot of people gave me positive feedback which was awesome. I practiced a lot in front of co-workers (and my wife <3) which all gave me super good feedback.

How To Make Money From Your Software Blog Without Hosting Ads 💸

Alec Brunelle — Mon, 21 Oct 2019 12:59:47 +0000

Want more great content like this? Sign up for my newsletter, visit: alec.coffee/signup

We all know advertising sucks, but when it comes to writing blog articles and getting paid for it, a necessary evil. If you are a conscious online user, you care about leaving a minimal online footprint. You also know that advertising companies track every move a user makes online so that their banners are clicked through. You shouldn't have to subject your blog readers to ads so that you can make money. Leaving you with two options, either succumb to the ad overlords and add them to your blog or gate your content behind a paywall where little people get to read what you write. If you are starting, good luck making any return on blog ads as your views need to be in the thousands to return any profit. Hosting ads on your blog is also tough because most people block them, especially software developers, making them worthless. The good news is that there are great alternatives for people who want to get paid to write words, just like how people are paid to generate other sorts of online content, like videos on Youtube and stock photography.

The solutions I offer supplement posting on your personal blog, compared to another hosted platform. This way, you aren't subject to changes in a companies direction; examples being a platform doesn't have ads today but adds them tomorrow.

A little disclaimer, I have no disrespect for people who want to write and share knowledge online for free. Like open-source software, writing contributes positively to a vast amount of people. If you look at the other side of the spectrum, getting paid to write for a blog is like getting paid to write software, the people who value it highly and have the means to do so will donate funds. There are examples of how this works in open-source sponsorship programs, examples like Tidelift, Github Sponsors and Issuehunt, to name a few.

Medium

This platform is a place where writers of all disciplines can post their content, and when it's read paying you in the process. Their revenue model is simple, readers pay \$5 a month, and while interacting with content, funds get distributed to the pieces they interact with. So far, I haven't seen a platform that does the same with much success. Usually, writers have a tough time making money online; it's the sad truth. You may have a great story on your hands, but if you aren't out pitching to publishers every day, your story may never be read by that many people. Think of Medium as a publisher who lets most pieces in on the platform, but lets their algorithm do most of the work to get the user base to read it.

Cross-posting

If your writing only lives in Medium, you are potentially leaving out readers who don't use the platform. The group of people who want to read your blog content isn't the same exact group that uses Medium. While I'm advocating to put your content behind Medium's paywall (something I mentioned before was terrible), I'm not saying this is the only place your content should live. If you are like me, I want my content to be read by the most amount of people that it can. Medium's SEO is fantastic and most likely better than your blogs unless you are an SEO master. Not only that, but while on Medium itself, there is a feed that hands out recommendations. This feed is how you will get the majority of your views, at least I have from experience.

How I Use It

What I do, is first post content on my blog and dev.to, which gets some early feedback and gives me signals as to what is sticking and what isn't. I post a final edit to Medium and point the personal blog canonical_url to it, when search engines pick it, I want to use this link as it gives me money. To provide more traction for the post, I often submit them to Medium publications. To find a couple of top publications related to the content of the post, I use this website.

Read more about canonical URLs here

Patreon / Ko-Fi

For blogs, you usually don't see a Patreon link or a 'donate here' button. For me, I see anyone who produces content online as someone who should be using this. Just like streaming on Twitch or creating Youtube videos, writing takes time, and if someone has the funds, they will see donating to you via these platforms as viable, especially if they see you don't use advertising as a source of revenue. Offering subscriptions can go as far as you like to take it; you could offer monthly subscriptions, give higher tiers of subs earlier access to your writing or give them the ability to write you personally for Q/A. When you write more, your communication skills improving, people will want access to this.

How I Use It

For ko-fi, I signed up for an account and added a link to it in the bio on my blog.

Brave Rewards

After the Great Cambridge Analytical Scandal and many other events like it, I started to re-evaluate my online usage. I began to ween myself off apps from companies that use advertising as a source of revenue. One of the best alternatives to Google Chrome right now is the Brave Browser. It blocks ads while browsing, it does so at the browser networking level and not the Javascript level like most browser extensions do, giving performance benefits over a traditional browser extension. They knew that without ads, some websites couldn't exist, so they built in their own donation platform, which distributes funds to sites you visit and give attention to. Another option for users is to tip the website directly using the icon in the address bar.

How I Use It

After signing up to be a creator on Brave, that's it! When users visit your blog, if they have auto-contribute on, you will receive funds based on the amount of time they spent there.

Like this post? Consider buying me a coffee to support me writing more.

Want to receive quarterly emails with new posts? Signup for my newsletter

The Brave Browser just released a new way to support contributors on Github 🤑

Alec Brunelle — Fri, 04 Oct 2019 16:04:00 +0000

With the recent release of Brave (0.69), they have added a new way to share your Basic Attention Tokens on Github, through comments and issues.

Brave already had Github accounts setup to be channels for which users could send their tokens, but you had to visit their Github profile page. With this feature, it should be much easier for Brave users to tip.

Anyone think this is a good idea? Too pushy? It would be interesting to hear what people think.

DEV Community: Alec Brunelle

Running SQL Migrations Before Booting Docker Compose Services

A Bit of Background

What We Want

The Issues That Still Remain

Build a Next.js Blog with Cosmic’s GraphQL API

Choosing the Tech

Tutorial

Creating the Cosmic Project

Next.js local development

Cosmic Environment Variables

Looking inside the box

Deploying

Bonus

Previewing

Webhooks

Conclusion

Calm, Private and Healthy, A HEY Email Review

Email Hygiene

Ultimate privacy

The horror, vendor lock-in

Yet another thing to "learn"

Conclusion

A Better Way to use GraphQL Fragments in React

Show Time

This is the Way

Benefits

Less parent component coupling

Types become easier to maintain

Less chance of changes when developing component first

Trade-offs

Presentational components are not generic

Fragments sometimes become difficult to manage

Conclusion

How does your company handle research and investigation work?

Publishing a JavaScript Package to NPM automatically with Github Actions

semantic-release / semantic-release

📦🚀 Fully automated version management and package publishing

📦🚀 semantic-release

Fully automated version management and package publishing

Highlights

How does it work?

Commit

How It Works

The Next Version Number

Generating Release Notes

Automating With Github Actions

Steps to Take

Bonus

Yolk-HQ / next-utils

🥩 🍳 A set of Next.js HoC utilities to make your life easier

next-utils

Overview

Table of Contents

Installation

Note

🔮 Apollo Client

appWithApolloClient

Comment for #12

Quit Google Analytics, Self-hosted Gatsby Statistics with Ackee

Meet Ackee

Up and running on Heroku

Adding the tracker

Testing to make sure it worked

What you get

Alternatives

No tracking

Server-side analytics

Is knowing how to use Docker a prerequisite to becoming a Senior Software Developer?

1 year with Cypress: The Guide to End-To-End Testing 🚀

What's in the box

Prototyping

Decisions and Tradeoffs

Seeding Data

Writing Scenarios with Gherkin

Asserting Elements and Best Practices

Debugging

Visual Testing and Catching Regressions

Parallel Builds and the Cypress Dashboard

Browser Support