DEV Community: Ryan Doyle

Is Building Your Own Portfolio a Waste of Time?

Ryan Doyle — Sat, 13 Apr 2024 16:50:32 +0000

When you begin developing applications on your own for the first time, I would argue one of the first things that you do is build a portfolio website. Maybe you’re entering the job market for the first time and need to show off your skills. Or, perhaps you want to practice using a new tool, framework, or service.

While developing your portfolio is a great way to build up your development chops, in this post I’m going to outline some thoughts on why you might NOT want to build your portfolio and opt for using a site-building service instead.

Time & Effort

Developing any application on your own takes a lot of time and effort. One advantage over using an existing service (you’ve heard of them: Squarespace, Wix, Carrd, etc.) is that you’ll save a great deal of time when creating your portfolio. You might be thinking, “Exactly what I want! More practice!” While this is true, you could ask yourself, is that what you want to be practicing?

I would argue that at a point in your web development journey, you’re going to be practicing lower-level skills when making a portfolio. Of course, when you are brand new to web development, you need to practice layouts, styles, flexbox, grid, and all the things. Once you get these concepts down, however, I would argue there is no need to continually “practice” these skills. The world of web development is constantly evolving, and you’ll always have opportunities to practice the basics as you build…well, anything. Why spend time on a simple portfolio when you could spend time on something more complex?

Professional Design

Are you a professional designer? Maybe! But what if you are not? I for one am not a professional designer. Sure, I can make some cool layouts, but it only takes a quick Google Image search of unique or inspiring designs to remind myself that there are individuals out there in the world who are way more adept at creating compelling visual layouts or thinking of new ways to make information stand out in a sea of similar design.

So, could you design your own site? Sure! But chances are for most of us, that’s not our forte. There is a reason companies have UI, UX, and graphic designers working for them. Using a service allows you to avoid competing (visually) with what some of the best out there can do, and allows you more time to focus on developing your skills elsewhere.

Accessibility and User-Friendliness

One huge advantage to using a website building service for your site is that it’s almost guaranteed to be more accessible and user-friendly. Any good developer should have the capacity to create accessible websites and create a user-friendly UI, but that takes time. All that time you spend trying to make your site fit an endless amount of screen sizes could be a good practice at some point, but is it always the best way to spend your time? Maybe you have a side project that needs the same attention, and simply offloading that work for your site can allow you to use the same skills elsewhere, where you get more bang for your buck (time-wise).

Cost-Effectiveness

You might assume that using a service is going to cost more money than just making a simple. Honestly, that’s probably true if you generate a static site. However, quite often there is a lot of overhead with ensuring your static site is hosted somewhere that allows you to use a custom domain, or involves a lot of time taken when you need to rebuild your website or make a change.

This essentially brings us back to my first point, again, time and effort. While it’s possible to make a site for free, it’s almost always going to take you much more time to manage it yourself than to pay a couple of bucks a month for a service that is going to guarantee that x, y, and z are always up and running.

Consider a simple contact form. You’re going to need a whole email API or rely on some funky form feature (like Netlify forms) that lets you roundabout receive information from a submitted form. Not super elegant. Free? Yes. Easy? Debatable.

TLDR; Focus on higher-level projects

At the end of the day, my argument is this:

The purpose of a portfolio is for someone to be able to see your work, get some basic info about you, and perhaps contact you. While all of these features are essential to learn and be comfortable with developing yourself, it’s not very “high-leverage,” meaning…it’s pretty simple at the end of the day. Creating these features from scratch can take a good deal of time and oversight, so once you CAN do this on your own, it’s time to work on more complex projects that will stretch and grow you as a developer. Chances are, you’re still going to be continually creating everything you’d include on a portfolio site anyway.

So should you make your own portfolio? Maybe? But it might be time to question whether or not you waste time reworking portfolios constantly instead of spending your time challenging yourself in other ways.

Bonus: What I’m Using

So, what do I use, and why?

Currently, my portfolio site is built on carrd.co. I first discovered this site when looking for a simple landing page for my wife. Turns out, it was a great platform for a simple portfolio. I didn’t want my projects on my site, so much as a landing page for contact, resume, and forwarding anyone who finds it to where I have my actual projects (like Github).

If I wanted to have some example projects, I could easily add a few.

If I wanted a blog, videos, or something else, I’d probably go with something else like SquareSpace, although it’s more expensive and I don’t need/care for those features.

At the end of the day, it’s simple, but it took me about 20 minutes to get set up and now I have all the time in the day to work on other side projects, Leetcode challenges, or go outside.

Make a Secure Browser?

Ryan Doyle — Thu, 06 Aug 2020 01:28:45 +0000

Ok, so I’ve been working on a learning platform for making teacher created playlist of content. One of the next steps is to create some type of quiz situation.

As a teacher, I’ve used “locked browsers” before, where once a student begins a quiz their browser locks and they cannot navigate away or open new tabs until they either finish the quiz or exit/end it.

My question is...is there any way to do this from a web dev perspective, or are people just straight up making their own browsers? I can’t seem to find any way to do this from my searching online.

Easy Alerts with React Context

Ryan Doyle — Tue, 16 Jun 2020 21:12:20 +0000

What Are We Doing?

For the last few months I've been working on an education based project, and one of the challenges/decisions I had to make was how I was going to handle showing alerts once certain action were completed. There is a lot of content creation involved, so I wanted clear notifications that some action was successful (or not).

In general I wanted something super simple that just worked to start, but something I could expand later if I wanted to. For starters I just wanted to be able to do the following:

Have the alert persist if the page changed, in part so I could send the user to another page and not have to worry about the alert disappearing.
Look different depending on whether it's responding to a successful action or some error that came up.
Contain some basic information about what happened, and be able to customize it.

The Solution

I decided to use React Context to handle the alerts. If you've ever used context before you're probably like, "wow, shocker," but I hadn't seen anything online where someone was making alerts with context before. Usually what I found involved packages and things getting passed back and fourth in server requests, and I didn't want a package, I wanted my own deal.

So, my solution involved essentially 3 different things:

A context High Order Component that wraps the pages in my application with the context provider. (I'm building in Next.js)
Using the useContext hook to trigger the alert from pages throughout my application.
An Alert component that is shown/hidden based on the state of my HOC.

Let's look at each part so you can mimic/criticize my method 😆.

Context Provider HOC

If you're new to React Context, it essentially works on the premise that you can (1) create a context object that hold some type of state, (2) provide the context object to your applications using the context provider, and (3) use the context consumer to read the data from the context provider anywhere in your applications. It's a great way to provide application-wide state without having to pass props from one component to another component a half dozen times.

Below I have my High Order Component:

import React, { useState } from 'react';

import { AlertStatus } from '../../lib/enums';

const AlertContext = React.createContext(null);
AlertContext.displayName = 'AlertContext';

const AlertProvider = ({ children }) => {
  const [alert, setAlert] = useState(AlertStatus.None);
  const [alertText, setAlertText] = useState(null);

  return (
    <AlertContext.Provider
      value={{
        alert: alert,
        alertText: alertText,
        success: (text: string, timeout: number) => {
          setAlertText(text);
          setAlert(AlertStatus.Success);
          setTimeout(() => {
            setAlert(AlertStatus.None);
          }, timeout * 1000 || 10000)

        },
        error: (text: string, timeout: number) => {
          setAlertText(text);
          setAlert(AlertStatus.Error);
          setTimeout(() => {
            setAlert(AlertStatus.None);
          }, timeout * 1000 || 10000)
        },
        clear: () => (setAlert(AlertStatus.None)),
      }}
    >
      {children}
    </AlertContext.Provider>
  );
};

export { AlertProvider };
export default AlertContext;

Working through the above code, these are the main points:

Making the Provider Component

First I create the AlertContext and set the display name (for debugging)
Next, I create the Alert Provider component. With react context, you wrap up the application (or what parts of your app you want the context available to) in the AlertContext.Provider. The .Provider is a component available on all Context objects. So, I am essentially passing in {children} to my AlertContext.Provider so I can warp up whatever parts of my app in just a <AlertProvider> component, and it will have the context.

The Context `value`

React Context takes a 'value' which is the values that the context consumer can read. I've got 5 different aspects of my Alert value.

alert is a simple piece of state (using the useState hook) that is either set to "SUCCESS", "ERROR", or "NONE". In the code you'll notice that it's AlertStatus.None which is because I'm using typescript. But basically AlertStatus.None is equivalent to "NONE". You could use strings just as easily but I'm dipping my toes into TS so that's where I'm at.
alertText is a string that contains the text that will be shown in the alert. It's also just a piece of simple state set with the useState hook.
success is a method that accepts a string (and optionally a number value). This method changes the value of alertText, and then sets the alert to "SUCCESS". The optional number value determines how many seconds will elapse before the clear method runs.
error is the same thing as the success, but it set the alert to "ERROR".
clear is a method that just sets the alert to "NONE".

Using the Context Provider HOC in App

I am using Next.js for my application, so I have a custom _app.jsx that has the main structure of my application. Below you can see the entire thing so far.

function MyApp({ Component, pageProps }) {
  return (
    <ThemeProvider theme={theme}>
      <UserProvider>
        <AlertProvider>
          <ModalProvider>
            <Global styles={global} />
            <Head>
              <script src="https://apis.google.com/js/platform.js" async defer></script>
            </Head>
            <div css={layout}>
              <NavPanel />
              <main>
                <ComponentWithRoles Component={Component} pageProps={pageProps} />
                <Alert />
                <Modal />
              </main>
            </div>
          </ModalProvider>
        </AlertProvider>
      </UserProvider>
    </ThemeProvider>
  )
}

The most import thing to note is that we have the AlertProvider (along with a few other Providers) that is wrapping up the application. I could probably just wrap up the <main>, but currently I have it wrapping most everything up, which makes the context available to every component within the <AlertProvider>. Nice.

Triggering Alerts!

Now the best part, triggering alerts!

Ok, so in my application I am using GraphQL and Apollo, so below I have an example of a Mutation for enrolling a student in a class. If you're not familiar with Apollo or GraphQL, essentially the mutation is just the part of the logic that's writing information to the database. Within the useMutation hook, there is an object that allows you to do something once the operation has completed, or if there is an error.

import AlertContext from '../context/AlertContext';

const EnrollForm = () => {
  const alert = useContext(AlertContext);

  const [enroll, { data }] = useMutation(ENROLL_MUTATION, {
    onCompleted: (data) => {
      alert.success(`Successfully enrolled in class!`)
    },
    onError: (data) => (alert.error(`Ooops, looks like there was a problem. ${data}`)),
  }
  )

  ... all the other stuff...
}

So, really the only important parts are:

Import the AlertContext. This is exported from the initial HOC component we made.
Use the React useContext hook to access the Alert Context (which we have access to because it's provided to our component way up in the component tree).

After that, you can call the methods that were made in the context object! So in the Apollo useMutation, you are able to execute a callback if the mutation was successful or not. So, within the onCompleted and onError in the Apollo mutation hook (or any other place you would want) you can simply call alert.success, alert.error, or alert.clear from the context! Calling the methods changes the alert value of the context to the "SUCCESS", "ERROR", or "NONE" which we can use to show an actual alert.

Actually Showing Alerts

So, we have logic for alerts set up...but what's actually showing up as an alert?!

For this, I have another Component, the <Alert> component. You may have noticed it earlier from above in the entire ._app.

Here is an ultra simplified version without any styling:

const Alert = () => {
  const alert = useContext(AlertContext);
  if (alert.alert !== 'NONE') {
    return <p>Hey there, I'm the alert! {alert.alertText}</p>
  } else {
    return null;
  }
}

First, you gotta pull in the AlertContext using the useContext hook, just like when you want to trigger the alert methods.

After that we can conditionally render an alert by checking on alert.alert. Remember, that would be either "SUCCESS", "ERROR", or "NONE". So if the value is not "NONE", the component renders. If the alert.alert value is "NONE" then null is returned, so nothing shows.

The default methods in the alert context will always call the .clear() method after 10 seconds if nothing else is specified, which will make the alert disappear, but in my actual component I also include a button to close the alert manually using the context.clear(), just like using the success and error methods. Another thing I do in the real thing is render different styles based on whether or not the alert.alert is returning "SUCCESS" or "ERROR".

So, that's it! Feel free to leave thoughts/ideas!

Making New Projects with Gatsby & Sanity

Ryan Doyle — Sun, 20 Oct 2019 01:45:34 +0000

Why Gatsby & Sanity?

As I've spent more time developing, one thing I have been doing more often is building personal sites for other people. It's an easy way to keep practicing new frontend skills and techniques, as well as build up a portfolio that shows what you can do. One of the most annoying things about this, however, is creating an easy and custom way to manage content for those websites. There are tons of options out there like WordPress, but one of my favorite tools is Gatsby.

Why I like Gatsby

Gatsby is a super-fast static site builder with arguably the best documentation I've ever encountered. As a dev, it's an incredible platform. Gatsby is essentially data agnostic, meaning you can use nearly any data type to provide it with content. It could be a WordPress API, markdown, RSS feeds, it's great. Lately, my choice is for managing content easily is Sanity.

Why I Like Sanity

Sanity is essentially a super slick headless CMS/backend service. What's great about Sanity is that it comes with the Sanity Studio, a React application that you can run locally or host on a service such as Netlify. The beauty of it is that it allows you to define your own data types. The best way I can imagine explaining how it works (and why you would use it) is to compare it to a CMS such as Wordpress. With WordPress, you have pages and posts, and you can add tags and categories, but beyond that, you would essentially have to massage those types of data in an effort to create a site. That's confusing because the end-user could ultimately be dealing with having to manage data for their website that doesn't really describe their data appropriately. For example, if my wife (an actor) was using a platform such as Wordpress as a CMS and wanted to add a recent show that she performed to her resume, she might be making a new "Post" with a category. It works, but with Sanity, you could make your own data type called "Show" in the schema and that automatically creates a document type that could be edited by her (the end-user). For another example, I'm currently working on a site for a woodworker. They might want an area of their website that catalogs the different types of wood along with the wood properties for their readers. Using Sanity, I can make my own data-type for that. The great thing about Sanity is that you have the flexibility to create custom ways to store your data and manage your content (you can even edit the Sanity Studio itself because it's just a React app) all without having to set up your own database and manage all of that. For me, it's a happy space of having a custom CMS I can make for a particular client while not actually having to develop everything from scratch.

What We're Doing

In this post, I am going to be going over how to create a brand new, clean project in Gatsby and connecting it to Sanity as it's the primary data source. The Sanity site actually has a few starters you can use with just a few clicks, but it comes with a lot of pre-defined CSS, as well as the clutter of all the sample files that I don't necessarily want to deal with when starting a new project. Following these steps, you can grasp the basics of how Sanity and Gatsby work together and have a clean setup for both so you can use whatever you want for development, such as styling, file structure, etc. Here we go!

Steps

1 - Create Directory

So first we are going to create a directory for our project. I do this first because the CLI tools for Gatsby and Sanity are a little different and I also prefer to have both under a single git repo, so go ahead and make a directory named whatever, wherever you want. I named mine gatsby-sanity-starter.

2 - Create Sanity Studio

First, you need to install the Sanity CLI, so using npm run npm install -g @sanity/cli to install the CLI globally. After that, make a new directory in your root directory and name it studio. From the studio directory, run sanity init. The first time you do this you'll need to log in, create an account, and when prompted for a project, you are going to select Create a New Project and then for the project template you want to select Clean project with no defined schamas. This is going to create a brand new Sanity Studio inside the /studio directory.

3 - Create a Gatsby Site

If you have not already, install the Gatsby CLI with npm install -g gatsby-cli. Next, you're going to go to your root directory and run gatsby new web, which creates a new Gatsby project within the /web directory.

4 - Remove git from the Gatsby site

Next, we are going to remove git from the Gatsby site in the /web directory. This can be done by running rm -rf .git from within the /web directory. I prefer to do this because I like having a single git repo for both the studio (in /studio) and the actual website (in /web). Alternatively, you could run git init from within the /studio directory and have two separate repos for the studio and the website.

5 - Install gatsby-source-sanity

If you're new to Gatsby, a basic principle is that it uses plugins to incorporate various features. The plugin gatsby-source-sanity allows you to run GraphQL queries in your Gatbsy app against a GraphQL API route created by Sanity. You install this in a few steps.

From within the /web directory, run npm i gatsby-source-sanity --save.
Add the plugin config to the file gatsby-config.js

// in your gatsby-config.js
module.exports = {
  // ...
  plugins: [
    {
      resolve: 'gatsby-source-sanity',
      options: {
        projectId: 'abc123',
        dataset: 'blog',
        // a token with read permissions is required
        // if you have a private dataset
        token: process.env.MY_SANITY_TOKEN,
      },
    },
  ],
  // ...
}

Within the plugin config, you need to replace the projectId and dataset with your Sanity project id and dataset name. You can find this in the /studio/sanity.json file.

6 - Create Your Schema

At this point, in order to check everything is up and running properly in terms of the connections between your Gatsby site and Sanity you'll need to create some type of basic Schema. When we created a new Sanity site, it is 100% void of any schema, so there isn't a way to see anything getting pulled into you Gatsby site. We will do this in 2 steps.

Create the file blogPost.js and sponsor.js *in the schemas directory so you have */studio/schemas/blogPost.js and /studio/schemas/sponsor.js with the following.

// in blogPost.js
export default {
  name: 'blogPost',
  title: 'Blog post',
  type: 'document',
  fields: [
    // ... other fields ...
    {
      name: 'name',
      title: 'Name',
      type: 'string'
    },
    {
      name: 'sponsor',
      title: 'Sponsor',
      type: 'sponsor'
    }
  ]
}

// in sponsor.js
export default {
  name: 'sponsor',
  title: 'Sponsor',
  type: 'object',
  fields: [
    {
      name: 'name',
      title: 'Name',
      type: 'string'
    },
    {
      name: 'url',
      title: 'URL',
      type: 'url'
    }
  ]
}

Import blogPost and sponsor into the types in schema.js.

import createSchema from 'part:@sanity/base/schema-creator'
import schemaTypes from 'all:part:@sanity/base/schema-type'

import blogPost from './blogPost';
import sponsor from './sponsor';

export default createSchema({
  name: 'default',
  types: schemaTypes.concat([
    /* Your types here! */
    blogPost,
    sponsor
  ])
})

If you want to check out more about creating schemas in Sanity, the docs are here.

7 - Deploy GraphQL API

Anytime you modify your schema, you have to deploy your schema again so that your GraphQL API knows what's available to query. Since we just added a blogPost type and a sponsor type we need to deploy the API. We do this from /studio with the command sanity graphql deploy.

8 - Make Sample Blog Post

From /studio go ahead and run sanity start, and you can open up the Studio from localhost:3000. Here you should see the "Blog post" under Content, and you can click on that, and then the + button to create your first post. Just type in some filler info and move to the next step.

9 - Build Gatsby Site

Gatsby is a static site builder, so we need to build the site. Do this from /web with gatsby develop.

Once the site is built, you should be able to see the generic Gatsby starter page from localhost:8000, but if you head over to localhost:8000/__graphql you can see the graphQL playground. If all went well, there should be a few queries on the left that have Sanity in it, such as allSanityBlogPost. At this point, you can try running the query below and you should get data returned containing your blog post data you made.

query MyQuery {
  allSanityBlogPost {
    totalCount
    edges {
      node {
        _id
        name
      }
    }
  }
}

That's It!

Hopefully, now you have a clean Gatsby site hooked up to a Sanity Studio! From here, you can develop a Gatsby site however you normally would while you have new custom headless CMS through Sanity. Let me know how it goes!

GIT for Dummies

Ryan Doyle — Sun, 29 Sep 2019 00:03:01 +0000

Background

Ok, it's been a long time since I wrote a post. I thought maybe something super easy would be helpful for me to get going again. A few months back I did my first hackathon for an open-source project with Code4Sac. It was a great experience and one of the best things I gained was working with git for the first time on a project with other people. I know there are many ways that teams use git together, but I thought I would write up a quick list of commands you would want to know to get started working with others, as well as what they do. Finally, I'll sum it all up with a basic workflow example using all the commands.

Getting Started

Ok, first things first. You want to start a new project. Where do you start? If I was new to git/GitHub and wanted to have the easiest setup, I would start by creating a repo on Github. Starting this way will allow you to avoid having to hook up your existing project on your local machine with the remote repository on GitHub. (Yes there are sites other than Github, but if you are starting that's probably where you are)

So, head over to Github, make a new repository for your project then let's get started with the commands...

The Commands

git clone

With a brand new repo, you get an area that says "Quick Setup with a link to your repo. Copy that.

Alternatively, in an older repo, you'll have a nice green button that says "Clone or Download". There you can copy a link.

Head over to your terminal, then navigate to the directory you would want to have your new project in. Here you are going to enter the command:


 clone your_repo_link_here

Typing this command will make a copy of the entire repo on your local machine within a directory that has the repository name, and link it to the repository.(You can also copy the repo into the current directory, just place a "." at the end of the command)

git pull origin master

With a new project, you wouldn't need to pull, but after you start working on your project, or once you are working with others contributing to a project you'll need to make sure your repo is up to date. You do this by "pulling" the code down from your remote repository. We do this with:


 pull origin master

A quick note on what a REMOTE repository is. When you have git running on your computer locally, that's a repository just like the repository on Github. The term remote refers to a repository somewhere else. Most often when starting out, especially in this tutorial, the remote repository is also the "origin," where the repository was originally cloned from. But you could have multiple remote repositories, set up across different computers for example, and be able to update all of them from one computer. In this case, the remote repository just means the repo on Github we started with

So, basically this is the command you would use to make sure your local repo is up to date with the repo on Github. In this case, we are pulling from the origin, which is the remote repository that the project was cloned from (we cloned it from Github, so it's the origin of the repo) and we want to pull the code thats in the master branch.

In the future, you might work on other branches on the repository, in that case, you could pull down the code from Github by typing git pull origin whatever_branch_name_here.

git checkout

Ok! so let's says you're going to be doing some work now in your project. Generally, you want to do your work on a branch. A branch is essentially a copy of the project at a given point in time, and it allows you to work on the codebase without actually working on THE codebase. In a production environment, the idea is you wouldn't want to be directly editing the code that's running the show, so you take a copy, work with that, and later on combine your edits into the master branch, where all the magic is actually happening.

My favorite way to make a new branch is to use the command git checkout -b new-branch-name. Technically there is the git branch command to make a branch, and git checkout command to switch to a branch, but the git checkout -b with a name after allows you to make a new branch and switch to it all at once!

git add

Alright, so it's been a few minutes now and you've got some code typed up. You want to get that code on your local machine up to Github now everything is synced up. First, you need need to add the files you want to the "staging" area. Basically, up until this point, git knows you have made changes to some files but you have to say, "OK, not I am going to do something with all of these files here."

Super important note, you probably want to add a .gitignore file at the root of your project. In here you can add files to automatically ignore. You would definitely want to put in node_modules, as well as other things yo don't want to be tracked such as .env variables, or generated folders from things like Next, Gatsby, create-react-app, etc. You do this by typing the name of the file and/or folder on each line, separately.

I typically try and do this regularly as I work on each particular aspect/feature, so usually I add all my files at once to the staging area by typing in git add * but if you want to, you can add files individually by using git add filepath/name_here.

git commit

Once files are in the staging area, it allows us to make a commit, which kind of like saving everything at a point in history in git. Commits are nice because we can easily go back to certain commits if needed, as well as leave comments about what changes we made to help keep track of changes in our code.

So to make a commit, we use the command:
git commit -m 'descriptive message here'

That's basically it. The -m allows us to add a description immediately after.

git push

Now the part that actually syncs things up!

Thus far, basically everything has been on your local machine, but once you've made a commit (or a few) we can push all of the commits up to Github and the origin/remote repo online will mirror what we have on our machine.

Since you SHOULD be working on a branch, you would use the command:
git push origin the_branch_name

After pushing to the branch, you would be able to Github, see the branch, and do a pull request (or PR to the cool kids) that will pull the code from your branch into the master branch. Pulling your code into the master is what merges your changes to the master branch, which would be the main source of truth for everyone and the code in production (in most cases).

If you're being naughty or just working on your own project you might also do:
git push origin master
which bypasses the PR process and immediately pulls your new code into the master branch. Don't do that.

Workflow

Alright, so that's basically what I've used to get things done. But here is a scenario where you use all of them...

You're working on a project with a few people, it's been a few hours or days since you've worked on the project. You sit down on your comp and...

git pull origin master: Make sure everything is up to date! You might also pull from a branch you are working on instead of the master branch by using git pull origin branch_name.
git checkout -b some-branch-name: Make and checkout (go to) and new branch for your work, so you don't mess up what others are doing.
git add *: Add all the files you changed so you can make a commit once you've actually done something.
`git commit -m 'some helpful comment': Commit your changes so you can send the changes to the remote repository.
git push origin branch-name: Push all your commits up to the remote repository on Github to your specific branch.
Make a PR on Github. Your code after pushing is still in a separate branch online, so you need to make a pull request to merge it into the master codebase.

Nice job! You did work, kept everything synced up, and hopefully didn't screw up someone else's code!

Getting Started with PostgreSQL

Ryan Doyle — Fri, 14 Jun 2019 23:25:45 +0000

Why PostgreSQL?

In this post, I am going to be looking at creating a managed PostgreSQL (which from now on I'm just going to call a SQL database) and connecting to it using node_postgres. I have a decent amount of experience using MongoDB databases and have built a fairly good sized project using Prisma, which uses SQL behind the scenes but I had not ever had to actually write a SQL query and interact directly with a SQL database.

With Mongo Atlas (or mLab) and mongoose, it was extremely easy for me to find out how to get up and running but I was having a hard time just getting up and running with my own SQL database.

Here were the considerations:

I didn't want to use some weird free website that I would never be able to use in production.
I wanted it to be cheap (I was maybe successful?!)
It needed to be a real solution that I could see myself using in a real Node application. (opposed to using something like a GoDaddy server with a bunch of databases set up for me already)

Without further ado, here is what I'll be walking through:

Getting a DB up and running with DigitalOcean.
Setting up the config for your project in Node with node-postgres.
Creating a table and testing it.

Creating a PostgreSQL Database

If you haven't used DigitalOcean yet, it's pretty great. In short its a site where you can set up virtual servers among other things. At first, I tried to set up my own server with MySQL installed (which would have been about $5 a month to run) but that was becoming a bit of a beast to figure out, and ultimately my goal was to just be able to access a SQL database to be able to write a frontend application so I didn't want to spend all my time there. So...

I settled on a DigitalOcean managed database. That costs $15 a month, but it's cheaper than a course, it's legit, I saved me a bunch of time (I mean, people have full-time jobs managing databases) and DigitalOcean gives you referral codes that let you get credits for a certain amount of time (usually 30-60 days) and I had credit so it was free to try! If you want to give it a try sign up using my referral code and you can get $50 in credits for 30 days so it's free for you to get started.

Setting up the DigitalOcean Database

Sign up for DigitalOcean
Create a new project
Create a managed database. I used the PostgreSQL, which at the time of writing is the only option. You'll need to set up some options here but it's pretty self-explanatory.
The database will get created and you can see it in your project. Go to it to complete the setup.
Add your IP address so the database access isn't open to the public.
Download the SSL certificate, which we will use to connect.

Nice job! Your database is up and running.

Connecting to Database

I'm not trying to write a tutorial on how to make a whole application, so we are just going to tackle a few steps here. First, we will set up node-postgres, and then we will write a basic query to make a new table and log it to the console.

Project setup

To connect you only need 2 things, a .js file for conecting, and the .crt certificate you downloaded from DigitalOcean. Here is my structure.

postgresql-tutorial
  /certificate.crt (I renamed this)
  /connect.js (you can name whatever you want)

Set Up Connection

First, here is what I have to connect to my database. I got everything from the docs on node-postgres, but I left comments within to explain each part. You access all of the config options from your DigitalOcean, as seen from the photo below.

// node-postgres also support a pool connection, but I was more familiar with the Client type so I started with that
const { Client } = require('pg');
// fs is used to read the certificate
const fs = require('fs');

const config = {
  // everything here you can get from the "Connection Details" when viewing your database in DigitalOcean
  user: 'doadmin',
  host: 'db-postgresql-nyc1-21328-do-user-4669604-0.db.ondigitalocean.com',
  database: 'defaultdb',
  password: 'tqjgkd6uxyqger6n',
  port: 25060,
  /* You have to include the ssl options because DigitalOcean requires them.
  This is essentially just added on from the boilerplate config in the node-postgres docs */
  ssl : {
    rejectUnauthorized : false,
    ca: fs.readFileSync("./certificate.crt").toString(), //make sure name matches your certificate name you downloaded
  }
}

// creates a new Client instance with the config options above (you can also just put them directly in as argument)
const client = new Client(config);

// Connects! (Or tells me I don't know what I'm doing)
client.connect((err) => {
  if (err) {
    console.log("Connection error!", err)
  } else {
    console.log("Connection to DB successful")
  }
});

Testing out the database

With the code above (and your own config options since the ones above won't work anymore) you should see in your console that you are connecting. From here, it's pretty easy to work with the database. Basically, node-postgres has queries where you pass in a SQL query. I'm not getting into that much, after all, this was to get better at that in the first place. The query, if successful, will return a response object.

In the same connect.js file, add the code below.

const makeTable = `
  CREATE TABLE products (
  product_no integer,
  name text,
  price numeric
);`;

const testQuery = `SELECT * FROM products`

client.query(makeTable) //pass in the testQuery to see if making the table was successful
  .then(res => console.log(res))
  .catch(e => console.error(e))
  .then(() => client.end())

After adding those line, you should be able to run node connect.js and see a response object returned.

Essentially, client.query is taking in the makeTable SQL query (that I got from the PostgreSQL docs) which is a promise that will either log the response that's returned or log the error. Finally, the connection is closed.

You can see there is a second query testQuery which you can pass into client.query (replacing makeTable) and you should be able to get another response object that shows the details of the table you created at first.

That's it. Hopefully, someone else can find this useful and get up and running playing around with SQL in a real application!

I made this post pretty quick as my hands froze to death in and over-airconditioned Starbucks, so if something seems unclear please let me know so I can revise and clarify!

Java, C++, or C#???

Ryan Doyle — Wed, 05 Jun 2019 03:22:32 +0000

Alright. I would consider myself a new developer. I have worked primarily with Node, Javascript, and React and have been looking to enter the workforce as a developer.

In my search for a new career, I am of course always looking to develop my skills and learn more. As I look online (granted, this might just be in my area) I see a LOT of open positions for .NET, and many backend jobs looking for experience with Java.

The Question

My question is, as someone who would consider themself to be pretty strong on the Javascript/Node front, what would be a more beneficial programming language to seek out learning next? Would learning Java, C++, or C# make me a better programmer?*

Here are my first thoughts for each:

Java: It's all over the place, so it seems like it would be good ont he resume as well as a skill overall to understand. My first interview I bombed because it was for a backend Java position. (I applied for a Node/JS frontend position)
C++: It closely related to C (in my understanding). Apparently that can help a lot with other languages based on C. Also, I've heard it's good because it doesnt manage things like memory automatically so it makes you a better developer in the sense that you need to understand aspects of how the language works a little more than you might with other languages.
C#: Somewhat like C? Also it's part of the .NET stack which seems to have many jobs out there.

*I'm not necessarily looking for the best language to get a job right away. I'm trying to think more long term. That thinking leads me towards C++ because of what I said above, but not knowing any of these languages, I am hoping someone might have some more insight! I'd rather learn a language with skills that can apply across the board than something really specific to a certain stack, but then my locked in to that.

Or...maybe go the totally other direction and go with Swift?!

CORS in Apollo Client & Apollo Server

Ryan Doyle — Wed, 01 May 2019 17:00:03 +0000

This is a follow-up

Ok, a while back I asked a question and spent a few days trying to figure this out. I'm hoping that this can direct someone trying to solve the problem in the right direction. As a reference, this is the original post.

GraphQL Server Not Setting JWT Cookie

Ryan Doyle ・ Mar 31 '19

#help #express #react #apollo

My problem

So, my problem was that I had set up an Apollo Server with the backend hosted from a /backend directory and the frontend hosted from a separate directory at /frontend. My frontend was running on localhost:3000 and the backend I had running at localhost:4000. I was running into various problems with CORS as I tried to pass cookies along with requests, and I couldn't figure out what was going on. I also had a difficult time figuring out how to pass certain things (like user data) with requests.

My problem was, I was trying to pass along specific cors options, and I didn't know that Apollo Server came with default cors settings. Those settings were overriding and conflicting with what I needed

The Solution

My solution ended up being 2 parts:

Using the package apollo-server-express and the cors middleware.
Disabling the Apollo Server cors to avoid conflicts.



const express = require('express');
const { Prisma } = require('prisma-binding');
const { ApolloServer } = require('apollo-server-express');
const { importSchema } = require('graphql-import');
const cookieParser = require('cookie-parser');
const jwt = require('jsonwebtoken');
const cors = require('cors');
require('dotenv').config();

const typeDefs = importSchema('./src/schema.graphql');
const Query = require('./src/resolvers/Query');
const Mutation = require('./src/resolvers/Mutation');

const db = new Prisma({
  typeDefs: './generated/prisma.graphql',
  endpoint: process.env.DB_ENDPOINT,
  secret: process.env.DB_SECRET
});

const server = new ApolloServer({
  typeDefs,
  resolvers: {
    Mutation,
    Query
  },
  context: req => ({ ...req, db }),
});

const app = express();

var corsOptions = {
  origin: process.env.FRONTEND_URL,
  credentials: true // <-- REQUIRED backend setting
};

app.use(cors(corsOptions));
app.use(cookieParser());
app.use((req, res, next) => { // checks for user in cookies and adds userId to the requests
  const { token } = req.cookies;
  if (token) {
    const { userId } = jwt.verify(token, process.env.USER_SECRET);
    req.userId = userId;
  }
  next();
})
app.use(async (req, res, next) => {
  if (!req.userId) return next();
  const user = await db.query.user(
    { where: { id: req.userId } },
    '{id, permissions, email, name}' //the graphql query to pass to the user query
  );
  next();
})

server.applyMiddleware({
  app,
  path: '/',
  cors: false, // disables the apollo-server-express cors to allow the cors middleware use
})

app.listen({ port: 4000 }, () =>
  console.log(`🚀 Server ready at http://localhost:4000${server.graphqlPath}`)
);

This is my server/app set up as of now with everything working perfectly! Here are the main points and why I ended up implementing it that way.

Using apollo-server-express instead of apollo-server: This essentially allows you to create an express app and pass it to the server instead of using the vanilla app that Apollo Server creates on its own. It also allows you to create middlewares just as you would with a generic express based application and server!
app.use(cors(corsOptions)): For more granular cors options (I wanted the server to only listen to localhost:3000) you use the cors middleware and the options to listen to the origin you want, as well as the option to pass on credentials with requests.
server.applyMiddleware: It is here that you pass to the Apollo Server the express application, as well as the other important part, turn off the default cors options. Even though you turn off the default options, you are using the cors middleware in the express app you pass to the server, so it's all handled there.

GraphQL Basics - Part 5: GraphQL Queries in Apollo Client

Ryan Doyle — Tue, 30 Apr 2019 18:44:05 +0000

GraphQL Queries

To get started with GraphQL queries we are going to first take a look at what a GraphQL query looks like, then we are going to see what writing a query looks like in Apollo on the front end.

If you've been following along with this tutorial, we have the following data model so far:

type User {
  id: ID! @unique
  name: String!
}

type Item {
  itemId: ID! @unique
  name: String!
  cost: Int!
  shortDescription: String
  longDescription: String
}

Using GraphQL we can write a query for a specific user the following way:

{
  query GET_USER_QUERY {
    user {
      id
      name
    }
  }
}

Here what each level has going on:

query GET_USER: This establishes we are writing a query, and we give it the name GET_USER_QUERY. I just like to add 'query' or 'mutation' in the names for clarity sake.
user: This is the specific query. It's also what our Apollo Server is going to look for in the Resolvers. Basically, we are telling the graphQL server to run the "user" resolver, which is similar to making a request from website.com/user in a REST API.
id, name: Finally, inside of user, we state what we want to be returned, which is both the id and the name of the user. (Although, we could just ask for one of them if we wanted)

REST API and GraphQL Compared

If you are coming from the land of a REST API, this is a little different. Basically, with a REST API, you end up hitting a certain URL endpoint, such as somesite.com/user and passing a query or params to the URL. You could use an express server to take those query params and use them in whatever logic to talk to the database and return data to you. (Super brief explanation obviously, I'm assuming you have some familiarity)

In a REST API, you have endpoints that you hit for certain requests/posts. An example would be website.com/users to get a list of users or going to website.com/posts for a full list of posts. You need an endpoint for all the different requests.

With GraphQL your server is set up to accept all requests the same way, but similar to how a REST API has different endpoints where the logic for the requests goes, a GraphQL server has different RESOLVERS that tell each GraphQL how to be handled.

Writing the GraphQL Query from Frontend

Again, if you've been following along in the series, when we set up our graphQL server initially we were able to run queries against the sandbox endpoint (localhost:4000 on our project). That's great but, we need to be able to run the queries from our application, here's how we could do that!

Adding Users to Prisma DB
First thing's first, we need to add a few users to our database in order to have something to query. We could do this programmatically, but I think that queries are easier to start within GraphQL, Prisma, and Apollo so what I did was just go into my Prisma DB, and add some users directly from the Prisma Admin.

Go to your Users in the admin console, and there is a + button (I highlighted it in yellow in the photo above) where you can just click to add users directly.
Add graphql-tag
We need to add the package graphql-tag to our project. This lets us use template literals to parse the GraphQL language into out Apollo Queries. Simply npm i graphql-tag!
Make a Users Component
Ok! So to write a query, we first need a component. We first need to create a file named Users.js in our projects frontend/components directory. Inside we need to require a few things (in addition to the normal react stuff dependencies).
- graphql-tag: For wrapping out GraphQL queries.
- Query: The Query render prop from the react-apollo library. We should have a basic start like below:

  import React, { Component } from 'react';
  import gql from 'graphql-tag';
  import { Query } from 'react-apollo';


  class Users extends Component {
    render() {
      return (
        <p>I'm the user component.</p>
      );
    }
  }

  export default Users;

Add GraphQL Query to the User Component Next, we need to add the actual query. To get a better idea of the flow of writing a query from scratch, we are going to be making a query to get ALL users. To do this we use the gql tag and create a variable that holds the query in the gql tag.

const GET_USERS_QUERY = gql`
  query GET_USERS_QUERY {
    users {
      id
      name
    }
  }
`;

Using the Query Component in Apollo Client To run our query, we use the Query component from Apollo Client. This is essentially a render prop that accepts our query as a prop, and behind the science runs the query against the database and returns data for us to work with!

To start off making sure everything is working, within the class we can put our component, passing the query as a prop, and within that, we have a single function that returns "data".

class Users extends Component {
  render() {
    return (
      <Query query={GET_USERS_QUERY}>
        {(data) => {
          console.log(data)
          return <p>check log</p>
        }}
      </Query>
    );
  }
}

You can see how our function accepts data that get returned from the query, and currenlty we are simply returning a paragraph tag that say "check log" because we are logging the data to the console.

Make a User Page To see anything we need to make a new page that we can navigate to in our application. In the frontend/pages directory, I made a new file named users.js and put the following:

import React from 'react';
import Users from '../components/User';

const users = () => {
  return (
    <Users />
  );
};

export default users;

Because we are using Next.js, making a new component in the /pages directory will create the users route and that's where we put out Users component.

Now we should be able to go to localhost:3000/users, and see our data in the logs!

OOPS. Fixing Errors Ok, if you have been following along 100% you now see errors. Full disclosure, I didn't plan this all out ahead of time and one problem I realized along the way is when setting up our servers, there are some CORS problems due to our frontend and backend being from different locations.

This can all be fixed by changing our backend/index.js to look like this:

const express = require('express');
const { Prisma } = require('prisma-binding');
const { ApolloServer } = require('apollo-server-express');
const { importSchema } = require('graphql-import');
const cors = require('cors');

const typeDefs = importSchema('./src/schema.graphql');
const Query = require('./src/Query');
const Mutation = require('./src/Mutation');

const db = new Prisma({
  typeDefs: './generated/prisma.graphql',
  endpoint: 'https://us1.prisma.sh/prisma-tutorial/prisma-graphql-tutorial/dev',
  secret: 'currentlyDrinkingPhilzCoffee'
});

const server = new ApolloServer({
  typeDefs,
  resolvers: {
    Mutation,
    Query
  },
  context: ({ req }) => ({
    ...req,
    db
  })
})

const app = express();

var corsOptions = {
  origin: 'http://localhost:3000',
  credentials: true // includes headers for the requests to backend
}

app.use(cors(corsOptions));

server.applyMiddleware({
  app,
  path: '/',
  cors: false // disbles default apollo-server cors and uses the express middleware cors in-lieu. 
})

app.listen({ port: 4000}, () => 
  console.log(`🚀 Server ready at localhost:4000`)
);

This is pretty similar to what we had before with one major adjustment. (Hopefully, the reasoning will be another post later on...) Apollo Server actually handles CORS by default, and this becomes a problem if your frontend and backend are hosted in different places. Essentially what I've done here is this:

Changed const { ApolloServer } = require('apollo-server') to require('apollo-server-express')
Created an express app
Added the cors middleware and passed it more specific options for out application, including the origin for frontend requests.
Applied the express middlewares to our express server, and set the Apollo Server cors to FALSE, meaning that the Apollo cors is disabled, and we are going to be using the cors middleware.

If all goes well, there should be NO http-header errors anymore! But we still don't get any data returned, why is that? Well, we created a query for users but we didn't give our Apollo server any resolvers to deal with the query. So far we only have a single query for an individual user. The final step should be making a resolver for actually fetching all users.

Users Resolver This is pretty simple actually. First, go to backend/src/schema.graphql and add a users query to our graphql schema. The Query type should look like this after adding the users:

type Query {
  user(id: ID!): User
  users: [User]
}

So, we added a users query, and that's going to return an array of User objects.

Next, we need to write the logic for the Query, so we head to backend/src/Query.js and create a users query after the user query we already had.

const Query = {
  user(parent, args, context, info) {
    if (!context.request.userId) {
      return null;
    }
    return context.db.query.user({
      where: { id: context.request.userId }
    }, info);
  },
  users(parent, args, context, info) {
    return context.db.query.users();
  }
};

This is a pretty straightforward query due to the fact we are asking for ALL users. We are just accessing the Prisma users() method, made available to us because we passed it into the context object way back when the server was made. So we are accessing the context, then out Prisma database (db), then we are accessing the prisma queries, and calling users() with no additional options. (You can pass users() more options, but we just want all users).

Query Done!

At this point, (errors fixed and all) you should be able to go to localhost:3000/users and see logged to the console a data object with all of the users somewhere. I have what I see below.

You can see in the object that's returned, we actually have the users nested under data.users.

We have the data! But we can clean it up a little.

<Query query={GET_USERS_QUERY}>
        {({data: {users} }) => {
          return (
            users.map(user => {
              return <p key={user.id}>{user.name}</p>
            })
          )
        }}
      </Query>

Because we know that data we want is within "data" in the object, we can restructure that, and then further destructure the users within data. This lets us just access the array of users using "users." Within the return of the Query component, we can map through the array of users, returning a

tag with a "key" set to their id (React want's unique keys) and return the users name within the tag. So, if you had 4 users, you would just get a list of them all output to the DOM. Yay!

Recap

To recap, making a a query involves the following core steps:

Writing the query.
Adding the query to your GraphQL schema.
Creating a resolver to handle the query coming from the client.

Hopefully, this is a good intro to basic queries in Apollo and implementing them with our Prisma methods in the resolvers. Next step, mutations!

Critique My Resume!

Ryan Doyle — Tue, 16 Apr 2019 01:14:47 +0000

I know there have been some posts in the past where people critique resumes, but I haven't seen one for a while. Are there any long-time devs out there willing to check out my resume and give some tips? Thanks!

Check it out here as a pdf

GraphQL Basics - Part 4: Connecting Frontend and Backend

Ryan Doyle — Mon, 15 Apr 2019 18:52:11 +0000

For those of you following along, sorry it been nearly a month since the last post in this series! I did start the series having everything already completed and it became evident that I still had some learning to do! Good for learning, bad for regular blog posts. I wrote this post because of all the learning:

Article No Longer Available

Let's Get started!

Getting Ready for the Frontend

Ok. The first thing we need to do is some housekeeping. (If you've been following along with me, we've got everything set up in a single folder. What I am going to be doing now is moving everything to a structure where the current files for the backend are in a "backend" folder while I have a separate "frontend" folder for all of that.

So, in the root of my project I added a backend folder and a frontend folder, then dropped everything that existed into the backend folder. I had to update all the require('') statements accordingly, but in VS Code it all happened automatically for me.

So now we've got this structure:

You should be able to go into backend/ in your terminal and make sure everything is working still by running nodemon index.js.

If everything is still good, I like to add a script in my package.json so I don't have to remember that command. In package.json, go ahead and add the following code. It will allow you to start up the backend server by typing npm run dev opposed to the nodemon index.js.



"scripts": {
    "dev": "nodemon index.js"
  },

Frontend with Next.js

For this project I will be using Next.js. It's a really robust framework that offers a lot of nice things like server-side rendering for React. It's also easy to get started with because it has features like a pages folder, where all component in that folder become pages you can navigate to. It also has a nice way to link to other pages that's super easy so it's great for this purpose.

Set up Next.js

First, we need to go into our frontend folder, and we are going to install Next, React, and React DOM. In addition, we also make a folder for our components, the pages, and a lib folder for a high order component.



npm init -y
npm install --save react react-dom next
mkdir pages components lib

With Next installed, we can now do a number of things!

Create a High Order Component for Apollo to work
Create a custom _app.js component (Main app that gets passed to the Apollo Client component)
Create a custom _document.js component (Overrides the normal document creation for server-side rendering.

Create a High Order Component

First, we need to install a few more things.



npm i --save next-with-apollo apollo-boost

Next With Apollo: This is basically a component that we pass our Apollo Client to which will eventually wrap up our entire application.
Apollo Boost: Apollo Boost is just a package that contains the most-used Apollo client packages. Essentially there a many individual packages you can use, but most people use a core set, so they have them all as apollo-boost.

To make the HOC component, I created ApolloHOC.js in my lib folder.



import withApollo from 'next-with-apollo';
import ApolloClient from 'apollo-boost';

function createClient({ headers }) {
  return new ApolloClient({
    uri: process.env.NODE_ENV === 'development' ? `http://localhost:4000` : `http://localhost:4000`,
    request: operation => {
      operation.setContext({
        fetchOptions: {
          credentials: 'include',
        },
        headers,
      });
    },
  });
}

export default withApollo(createClient);

So, let's walk through the code above. First we import next-with-apollo and apollo-boost.

Next we are creating the function createClient, which accepts headers (for SSR) and returns an instance of the Apollo Client. To that, we pass in the endpoint of our backend (the localhost:4000) as well as set the requests to include the header credentials with all requests, and also pass along those headers.

Basically, we need to pass the headers along with all requests (this is something happening from next-with-apollo) and also set credential to "include" so our app could do authentication if we wanted to. Overkill for this tutorial, but a good starting place for other projects.

Finally, we export the HOC withApollo that we require from next-with-apollo, passing in out Apollo Client.

Create our custom _app.js

Next, we need to create a custom _app.js file in out pages directory. This is pretty well documented in the Next.js docs but it essentially is where we wrap up our entire app with the withApollo component to expose our entire frontend to the Apollo Client. My custom _app.js is as follows.



import App, { Container } from 'next/app';
import { ApolloProvider } from 'react-apollo';
import withApollo from '../lib/ApolloHOC';

class MyApp extends App {
  static async getInitialProps({ Component, ctx }) {
    let pageProps = {};

    if (Component.getInitialProps) {
      pageProps = await Component.getInitialProps(ctx);
    }

    return { pageProps };
  }

  render() {
    const { Component, pageProps, apollo } = this.props;
    return (
      <Container>
        <ApolloProvider client={apollo}>
            <Component {...pageProps} />
        </ApolloProvider>
      </Container>
    );
  }
}

export default withApollo(MyApp);

Basically, the only difference between mine (above) and the example provided in the Next.js docs is that I also destructure apollo from the props and that gets put in the ApolloProvider as props. I don't actually remember where I found these examples, but the docs for the Apollo Provider explains wrapping your app. Alright, so now our components should have access to the Apollo Client!

Create custom _document.js

Another thing that I do is create a custom _document.js. The custom document is to "Is used to change the initial server-side rendered document markup". Basically, I mostly use this to hook up Styled Components, but it seems like for server-side rendering it has a lot of uses.



import Document, { Head, Main, NextScript } from 'next/document';
import { ServerStyleSheet } from 'styled-components';

export default class MyDocument extends Document {
  static getInitialProps({ renderPage }) {
    const sheet = new ServerStyleSheet();
    const page = renderPage(App => props => sheet.collectStyles(<App {...props} />));
    const styleTags = sheet.getStyleElement();
    return { ...page, styleTags };
  }

  render() {
    return (
      <html>
        <Head>{this.props.styleTags}</Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </html>
    );
  }
}

I got his custom _document.js from the Next.js Examples with Styled Components

A Few more Installs

If you try and start everything up right now, you'll get some errors due to some peer dependencies going on. I also have styled-components required in the _document.js so, let's install the following:



npm i --save styled-components graphql react-apollo

Basic Pages

To get ready for making out first graphQL query & mutation, we'll need a few basic pages. Go ahead and create the files addItem and viewItems in your pages directory and put in the following:

addItem.js



import React from 'react';

const addItem = () => {

  return (

    <div>

      <p>Add item form will go here</p>

    </div>

  );

};

export default addItem;

viewItems.js



import React from 'react';

const viewItems = () => {

  return (

    <div>

      <p>Items will show here!</p>

    </div>

  );

};

export default viewItems;

Check That Everything Works!

Ok, before checking that everything works, I will (same as the backend) go to my package.json in the frontend and add the script "dev":"next" and that will allow me to just type in npm run dev to start up the frontend.

You can now run npm run dev within the frontend and backend directories and be up and running! You should be able to navigate to localhost:3000/addItem to see "Add item form will go here" from our paragraph tag in the addItem.js file, and similarly for to localhost:3000/viewItems to see "Items will show here!".

All Set Up!

Hopefully, everything should be good to go now! In the next post, I'll look at creating a GraphQL Query!

Dealing with Setback (Also, how do you prepare for a blog series?)

Ryan Doyle — Sat, 06 Apr 2019 19:31:59 +0000

Error: Weren't You Doing a GraphQl Series?

A month or so I started a series on setting up GraphQL and Prisma with Apollo (Client & Server). Originally I was going to use a GraphQL Yoga server and just copy what I had done in a tutorial and explain what I learned, but someone suggested using the new Apollo Server 2. So, I went overachiever and decided to do that instead.

Turns out, I'm learning a ton more than I necessarily thought that I would, which is nice, but it also meant I had to stop that series for a while in the middle of it so I could make sure I actually knew what I was doing. Most of the problems being around passing authentication/headers/cookies back and fourth and not totally necessary for what I wanted to show, but I felt like I really didn't understand the tooling I was using since I was struggling with that.

So, first, how do you deal with setbacks? These are some of the things I did to get back on track.

1. Take a Break

This might seem counterintuitive, but taking a break is often what you need. It might be a break completely from the project, or just going and working on something else to get your mind in a new space. It's easy to get your mind stuck in a particular space. Sometimes we are focused on solving a problem a particular way and when you take a break you have a realization it might be something else, which leads you to look in a new direction.

2. Read Documentation

Sometimes, especially when you are new to a tool/framework/whatever, you just need to read the documentation in detail. For example, when trying to use a middleware to set up CORS between my servers I thought I had set it all up right, but kept getting the dreaded error that I didn't have the correct headers. After about an hour of trying all sorts of things, deep in the docs I find that my server has this all set up already, and it was overriding my more specific options from my middleware. That was causing the problem, and one line of cores: false, solved the problem.

3. Take a Step Back

Don't assume everything you've done is working. I think often we get caught up in thinking, "Iv'e done this thing x way before, so i'll implement it x way this time and it'll work great!" The problem is, maybe it won't work great and something you assume is working is causing a problem that leads you to think something else is an issue. Sometimes I will just go back to the beginning (or back to the start of whatever is the problem) and just start logging things out or testing smaller pieces to make sure everything is as expected. It can help limit your focus to what the real problem is.

How Does Everyone Prepare A Series?

Now that (as of today) I seem to have life in Apollo land all sorted out and I can start working on continuing my series on it, it got me thinking, How do people usually start a blog series?

I think in a perfect world you would have everything written out ahead of time, but that seems to be large time commitment that I don't really have at the moment.

The Question

If you have ever wrote a series of posts, how do you go about writing it, and if you have setbacks in the middle, what do you do about it?

DEV Community: Ryan Doyle

Is Building Your Own Portfolio a Waste of Time?

Time & Effort

Professional Design

Accessibility and User-Friendliness

Cost-Effectiveness

TLDR; Focus on higher-level projects

Bonus: What I’m Using

Make a Secure Browser?

Easy Alerts with React Context

What Are We Doing?

The Solution

Context Provider HOC

Making the Provider Component

The Context value

Using the Context Provider HOC in App

Triggering Alerts!

Actually Showing Alerts

Making New Projects with Gatsby & Sanity

Why Gatsby & Sanity?

Why I like Gatsby

Why I Like Sanity

What We're Doing

Steps

1 - Create Directory

2 - Create Sanity Studio

3 - Create a Gatsby Site

4 - Remove git from the Gatsby site

5 - Install gatsby-source-sanity

6 - Create Your Schema

7 - Deploy GraphQL API

8 - Make Sample Blog Post

9 - Build Gatsby Site

That's It!

GIT for Dummies

Background

Getting Started

The Commands

git clone

git pull origin master

git checkout

git add

git commit

git push

Workflow

Getting Started with PostgreSQL

Why PostgreSQL?

Creating a PostgreSQL Database

Setting up the DigitalOcean Database

Connecting to Database

Project setup

Set Up Connection

Testing out the database

Java, C++, or C#???

The Question

Here are my first thoughts for each:

CORS in Apollo Client & Apollo Server

This is a follow-up

GraphQL Server Not Setting JWT Cookie

Ryan Doyle ・ Mar 31 '19

My problem

The Solution

GraphQL Basics - Part 5: GraphQL Queries in Apollo Client

GraphQL Queries

REST API and GraphQL Compared

Writing the GraphQL Query from Frontend

Query Done!

Recap

Critique My Resume!

GraphQL Basics - Part 4: Connecting Frontend and Backend

Article No Longer Available

Getting Ready for the Frontend

Frontend with Next.js

Set up Next.js

Create a High Order Component

Create our custom _app.js

Create custom _document.js

A Few more Installs

Basic Pages

addItem.js

The Context `value`