DEV Community: Oliver

Learning GitOps with Helm Charts + Flux

Oliver — Fri, 31 Jan 2020 03:11:18 +0000

Earlier this month I built and deployed my first ever GitOps Continuous Delivery pipeline using kubernetes and flux. Throughout the process I found myself wading through quite a bit of outdated and confusing documentation, so having made it to the other side I wanted to write up a walk-through of the steps I took in the hopes that other developers can have an easier time.

The Stack:

AWS EKS for the kubernetes cluster
HelmOperator by Flux for GitOps
Terraform + Cloudformation for infrastructure

The application I deployed to the cluster was a GraphQL API that lives in a docker image on AWS ECR, but this can be adapted to any docker container or other containerized build.

Since there are a lot of good resources on creating a kubernetes cluster specific to whatever service you are using (AWS, Google GKE, etc) I am going to start this walk-through with the assumption that you have an existing cluster that you want to deploy an image to.

Step 1: GitHub

You will need a dedicated GitHub repository for this process. This is where you will commit all of the following configuration (your helm charts, helm releases, etc), and it should be separate from whatever repository you are using for building the application that you are deploying.

Step 2: Setting up Fluxcd

Follow the instructions for installing Helm and Fluxctl

Then, use helm to install the fluxcd charts:

helm repo add fluxcd https://charts.fluxcd.io

Create a namespace on your cluster for flux-related pods to live:

I used 'fluxcd' but you can choose whatever namespace makes sense for you

kubectl create ns fluxcd

Create your flux pod (the GitHub repo + branch will be from Step 1):

helm upgrade -i flux fluxcd/flux --wait \
  --namespace fluxcd \
  --set git.url=git@github.com:<GITHUB REPO> \
  --set git.branch=<BRANCH>

If your repository is private you will also need to add the knownhosts flag:

--set-file ssh.known_hosts=$known_hosts_path

pointing to the path where your knownhosts are, usually in the ~/.ssh directory.

Step 3: The Helm Operator

The helm operator is a controller that works in tandem with flux and allows you to create HelmReleases that will deploy an image, as well as update the image to the latest version whenever Flux detects a change.

Apply the Helm Operator to your cluster:

kubectl apply -f https://raw.githubusercontent.com/fluxcd/helm-operator/master/deploy/flux-helm-release-crd.yaml

Create the helmRelease pod:

helm upgrade -i helm-operator fluxcd/helm-operator --wait \
  --namespace fluxcd \
  --set helm.versions=v3

Retrieve the SSH Key:

fluxctl identity --k8s-fwd-ns fluxcd

and add it to your github repository under deploy keys.

You will want to give this key write access so that flux can update your helmReleases when it detects a new version of your image.

Step 4: HelmReleases

Now that flux is all set up, it's time to get to the good stuff. As I mentioned previously the HelmReleases are yaml files that flux will use to deploy an image.

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: <app name -- name of the application you're deploying>
  namespace: default
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.chart-image: glob:dev-*
spec:
  releaseName: <app name>
  helmVersion: v3
  chart:
    git: <github repo from step 1>
    path: <the directory where your charts live -- ex. charts/app-name >
    ref: <github branch set in step 2>
  values:
    image: <image endpoint of your application>
    replicaCount: 1
    hpa:
      enabled: true
      maxReplicas: 3
      cpu: 1
    extraEnvs:
      ## This is where you can add any public env variables
      username: oliver_2020
      dbServer: 11.0.1.213 
    envFrom:
      secretRef:
        ## The Secret Name for private env variables (more on that later)
        name: mysecrets

Each HelmRelease you have will need a corresponding Helm Chart. Helm has some great documentation on building custom Helm Charts + Templating, but I'll add the basics.

Step 5: Helm Charts

If kubernetes is the pilot, Helm is the steering wheel. Most Helm Charts contain the following components:

The Chart.yaml file is almost like the 'title page' of a helm chart. It consists of the chart name and version information.

apiVersion: v1
kind: application
description: A Super Awesome GraphQL API
name: graphql
version: 1.0.0

The values.yaml file is where you will define all the variables you will need for your chart.

image: <image endpoint of your application>
    replicaCount: 1
    hpa:
      enabled: true
      maxReplicas: 3
      cpu: 1
    extraEnvs:
      username: oliver_2020

These variables are then consumed by the various template files.

A common template file is the deployment template:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ template "app.name" . }}
    chart: {{ template "app.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ template "app.name" . }}
      release: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ template "app.name" . }}
        release: {{ .Release.Name }}
      annotations:
        prometheus.io/scrape: 'true'
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image }}"
          imagePullPolicy: {{ .Values.imagePullPolicy }}
          env:
            - name: publicEnvKey
              value: {{ .Values.extraEnv.key | quote }}
            - name: secretEnvKey
              valueFrom:
                secretKeyRef:
                  key: dbPassword
                  name: mysecrets
          resources:
{{ toYaml .Values.resources | indent 12 }}
    {{- with .Values.nodeSelector }}
      nodeSelector:
{{ toYaml . | indent 8 }}
    {{- end }}
    {{- with .Values.affinity }}
      affinity:
{{ toYaml . | indent 8 }}
    {{- end }}
    {{- with .Values.tolerations }}
      tolerations:
{{ toYaml . | indent 8 }}
    {{- end }}
      volumes:
      - name: data
        emptyDir: {}

You will have access to variables defined throughout your chart using the templating syntax

.Values
.Release
.Chart

However, if you need to change the structure of a value, for example to remove or add a hyphen, you can add a helper.tpl file. Template helpers are also useful for generating values like timestamps, where it wouldn't make sense to put it in your values.yaml file because it's not really integral to the chart.

Step 6: Template Helpers

Variables are defined in a helper file with the define action

{{- define "mychart.labels" }}
  labels:
    generator: helm
    date: {{ now | htmlDate }}
{{- end }}

You can then call this value in any of your template files with the template action

{{ template "mychart.labels" }}

which the template engine will read as the current date.

For a thorough reference on declaring custom values see the helm named templates guide

Step 7: Sealed Secrets

If you have any private env variables you want to use, it's good practice to store them in a secret. Kubernetes has a native way to store secrets but the values are only base64 encoded which isn't the safest strategy so I've been using a tool called sealed-secrets which allows you to create SealedSecrets resources that you can then store in GitHub because they can only be decrypted by the controller that created them.

A SealedSecret resource looks something like this:

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: mysecrets
  namespace: default
spec:
  encryptedData:
    dbPassword: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

and can be referenced in your helmRelease by the secret name

envFrom:
      secretRef:
        name: mysecrets

To begin, install the Stable repository:

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Update your Helm repositories:

helm repo update

and then install sealed-secrets from the stable repository:

helm install --namespace kube-system stable/sealed-secrets --generate-name

Once it's installed you can apply the sealed-secrets controller to you cluster:

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.9.6/controller.yaml

and then fetch the generated public key (this can be committed to GitHub) using the generated sealed secrets pod name:

kubeseal --fetch-cert \
  --controller-namespace=kube-system \
  --controller-name=sealed-secrets-230493143 \
  > pub-cert.pem

you can grab the pod name with kubectl get pods -n kube-system

Step 8: Creating a SealedSecret Resource

To create a Secret you will first generate it with kubectl and then ecrypt it with kubeseal

kubectl -n <env namespace> create secret generic <secretname> \
--from-literal=<key>=<value> \
--from-literal=<key>=<value> \
--dry-run \
-o json > <secretname>.json

the dry run flag will create the json file with base64 encrypted values, but will not create an actual kubernetes secret on your cluster.

To encrypt it with kubeseal you will pass in the location of the public key from the previous step, the name of the json file you just created, and the filename you want to use for your secret

kubeseal --format=yaml --cert=pub-cert.pem < secretname.json > secretname.yaml

This process will generate a custom SealedSecret resource that contains encrypted credentials that can only be unsealed by the controller that created it.

Once you have your SealedSecret resource you can delete or .gitignore the generated json file. When you commit the pub-cert file and the new SealedSecrets resource to GitHub flux will apply the secret to your cluster and then the controller will unseal it into a native kubernetes secret to be read by your cluster.

Step 9: Push To Git

Once your helm releases and corresponding helm charts are all set you can go ahead and push your commits to the GitHub repository from step 1.

Once your commits are merged or pushed to the branch you specified in step 2 flux will pick up the changes and deploy your first helm release.

Flux generally takes a minute or two to sync, but you can force a sync manually with

fluxctl sync --k8s-fwd-ns fluxcd

replacing fluxcd with whatever namespace you chose for your flux pod in step 2.

Step 10. TroubleShooting

If you pushed your commits, waited for flux to sync, and still aren't seeing the pod with the app-name from your helm release there are a few ways you can troubleshoot.

Get a list of all pods with kubectl get pods --all-namespaces and copy the name of the flux pod. Then run kubectl logs <fluxpodname> -n fluxcd

You should be able to see the logs of flux trying to clone the repo, and polling for updates, and can check for any errors.

Another strategy is kubectl get hr which will get all helm release instances, and will often show where the release is in the deployment process and any errors that came up.

Lastly, I always find it helpful to describe the resources and make sure they are configured as expected. You can describe any kubernetes resource with kubectl describe <resourcetype> <resourcename>

Conclusion

This is only one of many ways to configure a continuous delivery pipeline for your kubernetes pipeline. Flux is a great tool because it integrates well with Helm, and is a relatively straight forward way to automate the deployment process. Helm recently updated to version 3 and flux support for Helm v3 is still in beta mode, thus the somewhat confusing/outdated documentation, but the team at Weaveworks has been very responsive on their slack channel at https://cloud-native.slack.com/ and hopefully this walkthrough can help navigate some of the complexity as well.

Have questions, feedback, pictures of your pets? Don't hesitate to comment down below and happy coding!

How I got hired as a Bootcamp Grad (without a relevant degree)

Oliver — Thu, 25 Jul 2019 14:46:44 +0000

Back in September of 2018 I enrolled in Bloc.io, an online bootcamp designed to teach full-stack development (ReactJS on the front-end, and a choice of either Node or Rails on the backend). If you want to read about my experiences from during the program you can check out my previous posts, for this post I want to skip ahead and focus on that transition period between finishing bootcamp and getting a job as a developer.

I started my job search in March 2018, I officially graduated from Bloc in May, and I started my first job as a developer in June. Just to give a brief overview, between March and June I applied to 68 jobs, and interviewed with 11 different companies. I don't know if those numbers are average, and on a whole I would encourage you not to worry too much about numbers, I only mention it to show that it is perfectly normal to not interview with or even hear back from the majority of places that you apply to. Not hearing back is not a sign that you are never going to get a job, or that you aren't hire-able. It can be a stressful and disheartening process, but I hope that by sharing my strategy it might be a little easier.

Tip 1: Start early and get your application out there.
Start applying before you graduate, I suggest about two months before you finish but it depends on how long or short your program is. Regardless of whether or not you feel ready, get your resume written and just start applying. You could hear back, but more realistically this will serve as practice for some important skills -- quickly drafting up compelling cover letters, tailoring your resume based on the job requirements, finding relevant jobs, and getting used to putting yourself out there.

Quick note on cover letters: Early in my job search I was told not to bother with them, but in my experience these are essential for someone like me without a traditional tech background. If you have a CS degree having a stellar resume may be enough to get you considered, but if not, give yourself a chance by telling your story and making your own case for why you are worth hiring.

Tip 2: Track everything related to your job search. My bootcamp gave us a spreadsheet for this and it was honestly a life saver. Every time you apply somewhere, write down the date, company name, position title, company website, location, job posting url, your enthusiasm level about the position, how you found the job (career website, networking contact, cold outreach, personal connection), and your status (researching, applied, interviewing, rejected). You also want to track your interviews, questions asked, how you think you did, the name of who you interviewed with, etc. Lastly, I found it helpful to track my networking efforts as well. So, keeping track of meetups and who I met there, any informational interviews I went on, any cold outreach efforts I made and whether I heard back.

Tip 3: Networking. More specifically, making connections with experienced developers in your area. This is a big one so I'm going to split it into subsections: meetups, informational interviews, and getting your foot in the door

Meetups:

I started by going to a meetup called Code and Coffee in my area. Code and Coffee is a bi-monthly Saturday morning meetup with coffee and donuts where we just sit and work on personal projects or what ever other coding things we want to do.

Having connections to your local developer community is helpful not only for hearing about job opportunities, but for keeping up to date on new frameworks or strategies, keeping your skills sharp by working on personal projects, meeting people involved in open-source projects that you can help with (this will give you experience programming as a team), and just spending time in a space where people are excited about what they do.

You will also get practice talking about code, and being able to explain what you are doing, which is a super important skill for interviews but also just for working as a developer in general.

Informational Interviews:

If you haven't heard this term before, an informational interview is a semi-informal chat with the goal of learning more about the person and their experience in your field. This is a great place to learn from more experienced developers and ask lots of questions about how they keep their skills up to date, how they went about getting a job, the challenges of their work and how they get through them, etc etc. You don't want to talk too much about yourself here, this is about learning about them and their experiences. If you are part of a meetup already, ask someone there if they'd like to grab a coffee that week and share their experience. If not, you can reach out on twitter or linkedIn and send a message to a developer in your area. Looking for someone with some kind of connection to you is your best bet here, so look for someone who went to the same college as you (even if it was years apart), someone with a mutual acquaintance (even if it's super distant), or someone who also graduated from a coding bootcamp.

When you land an informational interview, make sure to look into their background and prepare some questions ahead of time for what you'd like to learn about them but try to keep it organic rather than a rapid-fire interrogation.

At the end, ALWAYS always try to leave with at least one name of someone else you can talk to. Something like, "Thanks so much for taking the time to meet with me, I really enjoyed hearing about ______, do you know of anyone else that would be open to chatting with me or that you think I should meet?" The more you grow your network, the more amazing people you get to meet and learn from, but also the higher the chance will be that you will know someone who knows someone who works at the company you are looking at applying to.

Getting your foot in the door:

Because of the high volume of applications, your number one best bet to scoring an interview is to connect with someone who already works there. This is where that awesome network you've been working on comes into play. Every time I found a job I was interested in I would go to LinkedIn look at the company and all of the employees and try to find any kind of connection between someone I know and someone who works there. Once I found it, I would reach out, mention our mutual connection "Hey, I noticed that you also went to Bloc" or "Hey, I noticed that you know _, I met them _" then, "I have been looking at the opening for a junior rails developer at ___ and I was wondering if you'd be open to chatting about your experience working there. Maybe we could set up a phone call or grab coffee".

When you meet with them, ask about what their day-to-day is like, how they feel about working there, what the company culture like, etc etc. This is your chance to get a look behind the scenes. Feel free to ask them about themselves and how they got into tech as well, this is also a great chance to ask what the interview processes looks like at this company. Towards the end of the conversation, bring up the position you are looking at. Briefly pitch why you are interested in the position/company and why you'd be a good fit, and ask if they know anyone who works on that team that you could speak with, or if they have any advice on how you might stand out as a candidate.

The key with networking is that you shouldn't go into a conversation with the goal of walking out with a job. Instead, it's an opportunity to learn from someone who has been where you are and who knows what it's like to actually work there. Networking is also a two way street, it benefits both the job seeker and the hiring team. Interviewing someone who already has the endorsement of someone who works for you can feel like less of a risk than interviewing someone from a pile of faceless applications.

Tip 4: Continue expanding your skills. Teach yourself stuff that wasn't covered in your bootcamp. Build things you are passionate about. As I mentioned before, my bootcamp had an option of node or rails for the backend. I chose node because I was already into JavaScript, but after graduating I taught myself ruby and rails as well and built a mini reddit-clone in rails just to get the hang of it. I also learned Redux for state management in React, D3 for data visualizations, and some other fun stuff. The point is, keep learning and keep building things.

As a developer things will always be changing, there will never be a point in your career where you know everything and can just coast. You need to be able to learn on your own, and know how to get yourself out of sticky situations, and practicing is the best way to do that. Then, when you are at interviews talk about what you've been working on that wasn't covered in your bootcamp, talk about how you got past that bug or what you've been learning on your own.

If you can, try to get some pair programming experience as well. Contributing to a local open source project is great for this, you can also ask someone in your meetup who is learning as well if they want to practice pair programming. I like to practice pairing on sites like CodeWars because it's low stakes, doesn't take any project set up, and is good practice for technical interviews.

Tip 5: Frame your lack of a formal CS degree as a positive. In undergrad I majored in fine arts at a liberal arts school, after graduation I went back to school to study education and spent some time working as a teacher. None of my formal degrees or work experiences are even tangentially related to computer science, but in my experience my background has made me a better developer and that is something I always expand on whenever I make my elevator pitch. Highlight your transferable skills and how your unique experiences have helped your work as a programmer. Let your background work for you instead of against you.

That's all for now, let me know if this was helpful and feel free to comment below or tweet me with any questions or thoughts at @mxoliverleigh

Redux within Full Stack JavaScript

Oliver — Thu, 16 May 2019 17:11:44 +0000

About a month ago I started the first sprint of my first ever full-stack JavaScript application. Previously I had worked with React in single-page applications, and I had built server-side applications with Node.js and Express, using EJS Templates for the view, but aside from having a theoretical understanding of the process, I had never actually experienced how the client and server connect and communicate. Enter Pocket Therabuddy, a full-stack NERD (node, express, react, database) application and mental health tool built with the intention of putting better data in the hands of users and the awareness to take control of how their actions can effect their moods in both positive and negative ways.

Pocket Therabuddy began as the capstone project for my nine month long bootcamp. The only stipulations for our capstone were that we had to follow the agile methodology throughout our planning and building process, otherwise we had complete free range over our tech stack, what we wanted to build, and how we wanted to build it. It has been a few weeks since I officially graduated, but this project is something I plan to continue for a long time. In my time as a teacher and now as a developer I have always emphasized project-centric learning because it allows you to be exposed to problems and topics you would have never thought to learn about otherwise. Which brings me to the crux of this article, one of the things I learned in building this project was the role of Redux in a full-stack JavaScript application.

Redux is in short a state management tool, but in keeping track of the state it can take charge of quite a lot of important logically processes including communicating with the server.

import { authHeader } from '../helpers/authHeader';

export const habitService = {
    addHabit,
    getHistory
}

async function addHabit(habit) {

    const requestOptions = {
        method: 'POST',
        headers: {'Content-Type': 'application/json'},
        body: JSON.stringify({habit: habit})
    }

    const response = await fetch(`${process.env.REACT_APP_API_URL}/api/habittracker/add_habit`, requestOptions);
    localStorage.setItem('habits', JSON.stringify(response));
    const res = handleResponse(response);
    return res;
}

async function getHistory(user) {
    const requestOptions = {
        method: 'GET',
        headers: authHeader()
    }

    const response = await fetch(`${process.env.REACT_APP_API_URL}/api/habittracker/${user.id}/history`, requestOptions);
    const res = handleResponse(response);
    return res;
}

This is a snippet of code with a GET request and POST request to the server. All in all pretty straight forward, the fun part is how redux handles making these requests.


function fetchHistory(id){
    return dispatch => {
        dispatch(request());

        habitService.getHistory(id).then((habits) => {
            dispatch(success(habits));

        },
        error => {
            request(failure(error.toString()));
            request(alertActions.error(error.toString()));
        })
    }

    function request() { return { type: habitConstants.HABIT_HISTORY_REQUEST }};
    function success(habits) { return { type: habitConstants.HABIT_HISTORY_SUCCESS, habits }};
    function failure(error) { return { type: habitConstants.HABIT_HISTORY_FAILURE, error }}; 
}

This is the action creator for the GET request above, this action which can be called in any react component with habitActions.getHistory(id) will dispatch the request, then call the habitService.getHistory function which is the GET request from before. If the request is successful, it will pass the JSON response from the server into dispatch(success(habits)) which can be accessed in the component as this.props.habits . On failure, it will dispatch the error.

The last part in this process is how you access your redux action creators and responses within the component. Redux has both a mapStateToProps method and a dispatchState method, though I have found personally that mapStateToProps can be used for pretty much everything.


function mapStateToProps(state) {
    const { user } = state.authentication;
    const { habits } = state.fetchHabits;
    return {
        user,
        habits
    }
}

This function here will get the currently logged in user (authentication, and fetchHabits are the names of the redux reducers that handle these states) and whichever habits are returned from the server request. This function should be located outside of your React class, either above or bellow.


componentDidMount(){        
   const { dispatch, user } = this.props;           
   dispatch(habitActions.fetchHistory(user.response));    
}

Here is the dispatch call that will trigger the action creator and service request we looked at above, which will set this.props.habits to the data returned from the server.

The last crucial but very simple part is the npm package react-redux which will give you access to the connect function

import { connect } from 'react-redux'

Then at the bottom of your component connect your redux mapStateToProps function to the name of your class Component and export it as usual.


const HabitHistory = connect(mapStateToProps)(ConnectedHabitHistory);
export default HabitHistory;

If you’d like to check out Pocket Therabuddy for yourself it is deployed here and you can find the GitHub repo here with more information about running it on your local server and upcoming features. Stay tuned for an article about d3 and using data visualization with React (another thing I learned in making Pocket Therabuddy).

— MxOliver

Role-based Authorization and the View

Oliver — Thu, 21 Mar 2019 14:26:57 +0000

Over the past few weeks I have been working on building a client-side wikipedia-esque web application using Node called Wikology. In Wikology, all standard members can create, edit, and read public wikis. Users can also upgrade to a premium account (using the Stripe API client for payment) and create private wikis which can only be read and edited by their collaborators.

In the past, when handling role based authorization and which CRUD (create, read, update, delete) functions user role’s are authorized for, all users, whether they were signed-in or not, had read access to everything. This meant that the majority of the authorization took place between the controllers and the model. I could easily pass in a policy class to my query files and check if a user was authorized before allowing them to continue with a CRUD action, and if they weren’t, I could flash an unauthorized notice and redirect them. With Wikology, the introduction of private wikis meant that read access was not a given for all users, and thus, role authorization had to be implemented not just between the model and controller, but also in the view.

So how does one implement role based authorization for CRUD methods in the view part of an application? If you are a seasoned developer this may seem like an obvious answer, but this was my second ever client-side application and I was about to reacquaint myself with the MVC framework on a whole other level.

The key to working with the View side of the Model-View-Controller framework is to think about how you are passing information to the view.


show(req, res, next){
        wikiQueries.getWiki(req.params.id, (err, wiki) => {
            if(err || wiki == null){
                res.redirect(404, "/wikis");
            } else if(wiki.private === false || 
(wiki.private == true && wiki.userId == req.user.id)){

                    wiki.body = markdown.toHTML(wiki.body);
                    wiki.title = markdown.toHTML(wiki.title);
                    res.render("wikis/show", 
                     {wiki: wiki, collaborator: null}
                    );
            } else if (wiki.private == true) {

               collaboratorQueries.collaboratorAccess(wiki.id,
               req.user.id, (err, collaborator) => {
                    if(err || collaborator == null) {

                        req.flash("notice", "You do not have permission
                        to view this wiki.");

                        res.redirect('/wikis');

                    } else {

                        wiki.body = markdown.toHTML(wiki.body);
                        wiki.title = markdown.toHTML(wiki.title);

                        res.render("wikis/show", 
                        {wiki: wiki, collaborator: collaborators);
                    }
                })  
            }
        })
    },

This is the show method which handles the view for each individual wiki. Let’s break this down:

Get the wiki — in order to do anything we need to retrieve the specific instance that matches the given wikiId.
Check if the wiki is private and if so, check if we are the owner — if the wiki is public, or if we wrote the wiki, we have guaranteed read access and can go ahead and render the view. Here we are passing the wiki from step 1 in as {wiki: wiki } and the collaborators as null because they aren’t relevant to the show method if we are the owner or if the wiki is public.
If it is private and we are not the owner, we need to retrieve the collaborators for this wiki — each Collaborator instance has a one-to-one relationship with User, and a one-to-many relationship with Wiki (eg. each collaborator instance only has one user and one wiki, but a wiki can have many collaborator instances). The specific query here is happening on my collaboratorQuery file (shown below) but the concept is fairly straightforward. I pass in the wikiId from step 1, as well as req.user.id which is the id of the user making the request. Notice I’m not trying to retrieve all of the collaborators for this wiki, I only need to know if the current user is a collaborator in order to determine their read access.


collaboratorAccess(wikiId, userId, callback){
        Collaborator.findOne({where: {wikiId: wikiId, userId: userId}})
        .then((collaborator) => {
            callback(null, collaborator);
        })
        .catch((err) => {
            callback(err);
        })
    }

If there is an error, or if a collaborator instance doesn’t exist between the current user and the wiki, the user is redirected and sent a message letting them know that they are not authorized to view that wiki.

However, if everything succeeds we can go ahead and call on the view to render the wiki. This time, we pass in {wiki: wiki, collaborator: collaborator} which not only passes the wiki to the view, but passes the collaborator instance that links the current user as a collaborator with the wiki. By passing the collaborator instance to the view I can make sure the current user has access to view the private wiki before it renders. Ideally the user would be redirected before they even reach the view, but if they were to enter the route manually (eg. a former collaborator who no longer has read access but knows the url route) this would double-check their authorization before rendering.

This same strategy can be used for the rest of the CRUD methods, passing in authorized users as collaborator instances in order to determine what should be rendered in the view. Other examples include, determining whether the edit and delete buttons should be visible to a given user, or which private wiki titles should appear on a user’s index page (eg. the ones that they own or collaborate on).

Whenever I am stuck on a problem, the most effective question I can ask myself is “Who knows what and how?” Essentially — Does this component have the information it needs to do what I am asking it to do? Where is that information coming from and how is it accessing that knowledge?
and remember if you’ve been staring at the same problem and getting nowhere — take a step back so you can see the forest for it’s trees.

— MxOliver