Forem: Kurt Kemple

The Developer Advocate's Guide to Addressing Product Friction

Kurt Kemple — Sat, 23 Oct 2021 03:06:09 +0000

Over the last three months, we've been developing a framework at Apollo called DX Audits to help us identify, document, report, and address product friction.

Our team and company is growing quickly and it was becoming increasingly difficult to address product friction. We wanted a framework that would help us make that part of developer advocacy more repeatable, teachable, and reportable.

So, with a rough outline of a framework and our eyes bright and full of hope, we embarked on a journey of experimentation that led us to some fascinating places. We cried, laughed, and cried some more, and in the end, we discovered that the fundamentals behind these audits were sound and can provide a lot of value, but we were working with the wrong separation of concerns!

In this article, I'll share what worked and what didn't work in the first version, how v2 differs from v1, and then we'll look at the updated DX audit process.

If you're not familiar with the first version of the DX Audit framework or if you just want to know what the framework looks like, you can skip to the "DX Audits v2" section.

What we learned

Overall the framework is solid. Adding structure around how we approach understanding developer pain points and delivering that feedback to other teams has largely impacted our dev advocacy work at Apollo.

Benefits

The biggest win of the process by far was the friction logs. They have already had a significant impact on our ability to demonstrate the problems community members are facing. Other teams loved the detailed walkthroughs and additional context that we could provide with our insider knowledge. Because we were looking at developer workflows holistically, it exposed friction that otherwise was undocumented or unknown.

Aside from friction logs, we also benefitted from the audit process in two other significant ways:

Consistency and structure - DX audits provide structure around what is otherwise an abstract part of developer advocacy. For example, our newest team member found it easier to understand how everyone approached delivering feedback because we all spoke the same language and followed the same process. On the other side, using the framework allowed us to extend that same consistency to other teams. For example, we now all deliver feedback in a unified format. A consistent method of feedback makes it easier for other teams to integrate it into their workflows.
Proof of impact - Ask any developer advocate what the most challenging part of the job is, and they'll likely say it's proving the impact they have. It's always been notoriously difficult to track the outcomes that stem from feedback. Now, we can keep track of our accomplishments in our DevRel database. Saving every friction log and action item that stems from an audit provides a direct paper trail from our work to the resulting changes made throughout the Apollo platform and the company.

Drawbacks

While overall, the process was a success, there were some issues with the first version of DX audits. Navigating any new approach will bring challenges, but the three things that caused significant friction (pun 100% intended) were:

Slow feedback loop - I listed consistency and structure as benefits from DX audits, but the framework created slow feedback loops in its original form. For example, with the cycle taking place over a few months, a friction log done in week two wouldn't technically get reported on or have any action items done to improve that friction for another five weeks or more.
Workload bottlenecks - With everyone on the team going through the cycle together, we ended up with surges in activity during certain stages and lulls in others. A more concrete example is that we released very little content during the build phase, but then during the implementation phase (now called the follow up phase), we had a surge of content in response to the findings in the audits.
Too much ceremony - We were doing way too much on the reporting front. I'm generally a big believer that you can't have too much documentation. Still, the original framework caused a lot of duplicated effort around documenting and reporting on our findings to others. So we spent a lot of time figuring out the best way to organize our feedback to be respectful of everyone's time and avoid duplication of communication.

Our epiphany

As I mentioned before, the framework was sound, but we used the wrong separation of concerns! The most significant issues we faced were related to timing. Forcing each use case to wait for all the others to advance to the next step in the process created a bottleneck, preventing value from being created until the very end of the process.

Now, audits are scoped to an individual use case, and developer advocates move through each step independently of other use cases. This allows us to provide value in a much shorter timeframe.

DX Audits v2

The goal of a DX audit is to document, report, and address product friction by having a developer advocate experience a given developer workflow, document and report their findings, and surface actionable steps to take to reduce friction.

An audit is scoped to a single use case that a developer advocate wants to experience. A use case is essentially a workflow that a developer would have to go through to complete a given task (i.e., add monitoring to a GraphQL server).

Audits consist of four steps. Discover, build, report, and follow up.

Download the full-size version.

Discover

This step is the work before the work. Discovery is where developer advocates should gather as much context about the use case they're about to audit. Depending on what initiates the audit, you might already have enough context to move ahead. However, there may be times you want to gather more information. In those cases, some great places to get feedback are:

Community and customers - GitHub, forums, social media, events, surveys and forms, issues raised by solutions, support and customer success, etc.
Input from stakeholders - product updates, roadmaps, engineering timelines, etc.

What makes these audits so valuable to others is that aside from identifying friction, we also use our insider knowledge to surface actionable steps we can take to remedy it. Your feedback is only as good as the context you have!

If you don't spend the time to make sure you have the full scope of the use case and have strong relationships with other teams, your feedback won't be as impactful as it could. Check out The Developer Advocate's Guide to Getting Buy-in to learn more about providing quality feedback.

Build

During this step, you'll work through the developer workflow from the previous step and record your experience in a friction log. Generally, developer advocates build a project that allows you to experience the workflow you want to audit.

What you build could be anything from an example app to working entirely within a given product UI. The important part is that you complete the workflow from start to finish with as much empathy and minimal assumptions as possible.

Friction logging is an excellent opportunity to create some content as well! For example, live streaming yourself going through these workflows and open-sourcing any projects you build can be a great resource of information for developers and an opportunity to get feedback from the community!

Here are some helpful best practices we've landed on for making the most out of friction logs!

Channel your empathy – You want to approach the workflow as a developer might. Try to make no assumptions and question if the step would be more difficult for someone without your insider knowledge.
More detail is better than less – The goal is to provide enough context about the steps you took to achieve your goal that anyone can read the document and understand or retrace your steps to reach the same outcome.
Don't forget the good – When you experience something delightful, make sure to document that and also be sure to include the positive experiences when summarizing a friction log!
Consistency is key – Everyone should be using the same template to create friction logs. Of course, DAs should have the freedom to use whatever tools allow them to be most productive, but friction logs need to be accessible and structured similarly.

Report

The purpose of this step is to create a clear outline of what we see as wins and issues and provide that feedback to related decision-makers as quickly as possible.

Developer advocates should use their best judgment when deciding where and when to deliver feedback from an audit. In scenarios where someone may not expect input, it's best to make sure you include the right people and that you've done enough work upfront to get the buy-in, you'll need.

Once a friction log is complete, the next step is to summarize and report your findings to involved parties. Add a detailed executive summary to the top of the friction log, including the highs and lows of the experience, any realizations or insights you uncovered. Be sure to document possible action items decision-makers could take to address any friction points discovered and add them to the friction log.

Follow Up

In this step, DAs work on the action items outlined in the friction log and track progress from any items that require cross-team collaboration.

It's essential to ask action item owners for a link to track the progress of the work. Having a direct link to the work done in response to your feedback allows you to 1) make sure you follow up and nothing falls through the cracks, and 2) directly connects the audit to every Jira issue, Airtable entry, or document that resulted from your feedback.

We use Airtable and some automation to make sure we see action items through to completion.

Conclusion

DX Audits provide structure and make it easier to teach, repeat, and report on a part of developer advocacy work that is difficult to quantify. Not only are the audits beneficial to the DevRel team, but many other teams at Apollo have found them valuable, and they are becoming a standard part of our collaboration process.

While the initial version of DX audits was beneficial in many ways, we didn't realize those benefits until the very end of the cycle. Scoping audits down to a single-use case allows us to deliver value much faster while still maintaining enough structure to support our goals around collaboration and consistency.

The Developer Advocate's Guide to Getting Buy-In

Kurt Kemple — Wed, 13 Oct 2021 04:20:22 +0000

It's finally time for your meeting with the Product team, and you're excited to share some feedback you got from the community. Not only that, but you even have an idea of how to fix the issue! You sit down at your computer, fire up that Zoom call, give yourself a quick check, and join. Eventually, your turn comes around, and you explain the problem and the possible fix. Everyone is super excited to receive your feedback and loves your idea! Victory!

You follow up and ask when they think they'll be able to prioritize that work. You eagerly wait as the product team talks about timelines and current projects, eventually saying, "We want to do it, but we're focused on X until the end of this year. So let's circle back." Finally, the meeting wraps up, everyone says their goodbyes, and you leave the meeting feeling frustrated. You know this issue is essential, so why are they not prioritizing it?

There are many reasons that decision-makers may not act upon the feedback we deliver. Still, one thing we can always ask ourselves is, "did I get enough buy-in before I asked them to commit?"

In this post, I'll cover what buy-in is, how it applies to developer advocacy, what skills help the most when trying to get buy-in, and the processes I use.

What is buy-in?

Buy-in is an agreement to support a decision. So, when we are trying to get buy-in, we're trying to get decision-makers to support our ideas. So, the act of getting buy-in is a process that involves building trust, communicating your ideas well, and hopefully creating champions so that when you ask for a commitment, you already have the right people on board.

Buy-in & developer advocacy

You might often hear developer advocates say they advocate on behalf of the community, but what exactly do they advocate for, and to who?

Developer advocates advocate for changes to a company's products, offerings, and software based on friction experienced by developers in the community.

Getting buy-in as a developer advocate is a unique challenge. We usually are not the owners or even direct contributors to what we're trying to change. Instead, we represent this bizarre ephemeral thing called a "community."

Because of this relationship, we have to be extremely careful in our approach to initiating change. We have to go the extra mile and make sure we've built a relationship with the people we need in our corner.

We need to take the time to make sure we understand what they are currently invested in, what effect our changes would have on their plans, and the amount of work it would take to make it happen.

Skills to develop for getting buy-in

One thing you might have noticed is that getting buy-in is all about working with other people. As such, the skills that will show the most dividends will be the ones that help you interface with the most complex computers of all, people.

Communication

Getting someone to support your ideas will be difficult if you cannot clearly state the problem, present a solution (if you have one), and provide enough context and supporting information to make informed decisions.

A significant part of developer advocacy is helping people understand their problems with a given product/technology and providing solutions. Lean on that!

Make sure to explain the problem in a relatable way to whoever it is you are trying to educate. Make sure you're framing the problem so that they can see how it will affect their success. For example, are they tracking MAUs (monthly active users) for a particular feature? Will this fix increase that metric? Look for commonality!

Empathy

It's important to remember that initiating change requires consent from all involved parties. So we need to build relationships with the people we'll ask to help us and ensure that the relationship is mutually beneficial. We can do that by understanding what goals they are working towards, what metrics they are concerned with, and what plans they have for the future.

When we include these things in our conversations with them, it shows we've thought about what effect our changes will have on them and how it could benefit them and goes a long way towards building trust.

Patience

Change is slow! Sometimes it might take a significant amount of time to get the buy-in you need to push something through. Depending on the size of the company you work for, this could be months for things that feel like they should be quick.

Make sure you're aware of product roadmaps and engineering timelines—plan for changes to take a while if adopted at all. Also, have fallbacks and short-term fixes to help reduce friction until you can get a proper fix.

Persistence

You might do all the right things and STILL not get buy-in. It happens! It's essential not to give up and look for other avenues to get the buy-in to initiate that change. This process is a cycle, and you repeat it until you get the desired outcome.

Look for other ways to help remove that friction for users. For example, are there any intermediate steps you can take or content that you can create to help people work through it?

It's important to constantly reassess the efficacy of the change as time goes on as it may become obsolete.

Tips for getting buy-in

So you know the skills you need to improve your odds of getting buy-in, but how do you put that into practice? Here are some of the tactics I've used to initiate change.

Collect data

Want to get someone on board for a change you are proposing? Show them quantitative data related to their goals, and it won't take much of a conversation.

Collect as much qualitative data and quantitative data as you possibly can. Qualitative data is feedback provided by the community or findings from your investigations. Quantitative data is the metrics that relate to the area you want to change.

Quantitative data is more valuable but usually harder to connect directly to a pain point developers are facing. Qualitative data holds less value but is generally easier to collect. If you lack quantitative data, it's essential to gather as much qualitative data as possible!

Record experiences

We know that empathy is an effective tool for helping us better understand the needs of people we communicate with, but we can also use empathy to help others understand the frustration users feel when they experience a particular pain point.

By recording either our own or users' experiences with a given workflow, we can clearly frame the issue for others. In addition, sometimes, users will experience the same pain point across multiple workflows, which helps outline the severity of the problem.

At Apollo, we use friction logs to record experiences.

Build desired outcomes

Building desired outcomes is a technique I brought over from my time as a tech lead. Tech lead is another position that is constantly initiating change. One of the techniques I came to rely upon was building prototypes or desired outcomes so that decision-makers could experience the change.

A more concrete example is when I wanted to adopt GraphQL at Major League Soccer. I knew it would solve many problems for us, but I needed everyone else to understand that too. Our existing architecture consisted of REST APIs, and our product managers would often examine data from these APIs due to partnerships we had with other companies.

Because they wanted to explore the data, we would build an "API browser" or small client application that allowed people to interact with the API through a UI. Since we discussed rewriting the API and versioning it again, I knew that we would need to build these UIs again. Knowing that product managers rely on this, I showed them how we could get the same functionality from GraphiQL if we adopted GraphQL. The idea of getting that same result without any development effort was exciting to them.

It's much easier to decide on something when you can experience its benefits before you build it.

Look for alignment

Sometimes getting enough buy-in can be the result of aligning your changes with existing plans to change something! So stay up to date on the product roadmap, look for opportunities to include your changes into a current initiative.

I recently spoke with someone trying to get the buy-in to dedicate engineering time to their navigation component. The existing solution was requesting the navigation metadata on the client-side. Not rendering the navigation on the server prevents some SEO benefits you get by having navigation be crawlable.

They have wanted to implement this fix for a while and tried to get buy-in for it previously. However, it wasn't until a new project for the navigation came along that they were able to resurface the change and finally get the buy-in they needed as the work aligned with the project.

Conclusion

As developer advocates, we'll often face situations where the best way to help the community is through initiating change. However, because we're generally asking people to change things they are responsible for, we have to be sure we're doing our due diligence to understand the changes we're asking people to make. We have to provide so much compelling evidence for our case that not only do they support our ideas but champion them as well.

Distributing Challenge: On Building Highly Engaged Teams

Kurt Kemple — Tue, 05 Oct 2021 01:53:21 +0000

I've been thinking a lot over the last few years about how vital the distribution of challenge is to a team's success.

In fact, it's one of the primary considerations I have when managing.

How many developers do you know who have left their job because either 1) the work is no longer challenging / there is no career growth, or 2) the work is too challenging, and they have no support?

Challenge plays an essential role in our happiness.

However, making sure that everyone on a team, in an org, or in a company is adequately challenged is a complicated task.

In response, I've developed a model called the Pyramid of Challenge that I use whenever I am managing others.

The Pryamid of Challenge

The model is composed of a triangle which represents a group's entire workload. The x axis represents the amount of work available and the y axis represents the complexity of the work available. Together they represent that as work increases in complexity, it decreases in availablity.

Ensuring everyone is challenged is about ensuring everyone on the team has the correct workload.

Balancing the Distribution of Challenge

In order to have a balanced distribution of challenge, you need a team makeup that doesn't leave any gaps in the pyramid or put too many people into one part of the pyramid, creating a challenge gap.

A challenge gap is an area of responsibility for a team that either doesn't have anyone challenged by that work, or the work is too challenging for anyone on the team.

When you compare that previous illustration to most teams today, it's starkly different. So is this a practical model?

If we apply the model to the responsibilities of a team tasked with building an application, you can see that it holds up. As the work decreases in complexity it increases in availability.

You only need 1 or 2 people to architect an application, but you'll need many more to build it.

So why is this important?

It's important because if we don't provide people with the right level of responsibilities so that they are properly challenged it could grind your team's productivity to a halt.

With a model to work from, let's look at some of the most common team makeups you'll come across and discuss some of the challenge gaps they face.

A challenge gap is an area of responsibility for a team that either doesn't have anyone challenged by that work, or the work is too challenging for anyone on the team.

Analyzing Common Distributions of Challenge

As we look at these distributions, it's important to remember that teams will come in all different sizes and makeups, and some teams that fit into one of these common distributions might be really high performing, happy, and engaged.

It's also very likely that teams will more accurately reflect a combination of these distributions. This model is meant as a guide to help you create a holistic view of your teams makeup according to their experience level and the work available for the team.

Top Distribution of Challenge

Let's start with the most common distribution of challenge, the top distribution. If a team has too many senior members, it suffers from a challenge gap at the bottom of the pyramid.

Senior developers are forced to do the less complex and more frequent tasks even though it's not challenging, essentially leaving them toiling. These teams could suffer from overly complex software, inability to reach consensus, and high turnover as team members leave to seek new challenges.

Bottom Distribution of Challenge

Another makeup we see often is bottom-distributed teams or a team without enough seniorty or leadership. These teams suffer from a challenge gap at the top of the pyramid.

These teams face a situation where they are overchallenged by not having the skills/experience needed to meet their responsibilities. Team members are likely to suffer from burnout and software could be brittle without proper guidance from more experienced developers.

Opposing Distribution of Challenge

Another makeup you might see is the opposing distribution of challenges. These teams tend to have one or two very senior people and then more junior developers.

These teams face a challenge gap at the center of the pyramid.

With an opposing distribution of challenges, senior developers will be forced to work on all non-challenging tasks that more junior developers aren't capable of handling yet, while also tyring to mentoring them.

This will greatly impact their ability to handle their own responsibilities while other responsibilities get dropped or mishandled.

The less experienced developers won't get the support they need and will often be tasked with work outside their current skillset.

Centered Distribution of Challenge

Lastly, we have a centered distribution of challenges. In this scenario, teams consist of mid-level developers but lack any really senior or more junior developers creating a challenge gap at each end of the pyramid.

Teams with this makeup are susceptible to infighting around responsibilities looking for work that will fit within their comfort zone. Some of the work could be too complex causing fragility in the solutions.

It's also possible for teams of this makeup to be very process heavy as team members look for ways to contribute. Some team members may try to step up and take on responsibilities that are too challenging to fill gaps and burnout.

A Framework for Growth

Another significant benefit I've found from using this model is that it creates a system that makes it easier to scale a team or teams as you take on more responsibility because the pyramid can be applied to any level of challenge.

Caveats & Conclusion

When it comes to humans we're better served by communication than models.

While this model might help you identify potential gaps in challenge, it's more important to constantly check in with your team and make sure they are in fact happy, engaged, and challenged appropriately.

Visualizing Focus with Neurosity's Notion and AWS Amplify

Kurt Kemple — Thu, 16 Jan 2020 16:36:44 +0000

That brain of mine is something more than merely mortal, as time will show. - Ada Lovelace

Right now, billions of people around the world are tracking their health with some sort of device. Heart rate, sleeping patterns, exercise, steps taken, calories in and out, all kinds of metrics are recorded to help individuals better understand what their body is doing.

However, none of this data can help you understand what's going on in your brain. It's unfortunately difficult to monitor your brain activity, this is where Neurosity comes in. I was lucky enough to be selected to try out the first edition of their headset, the Notion.

The Notion reads your brainwaves and allows you to collection data about things like your calmness or focus, as well as train models to execute certain commands when it encounters the corresponding brainwaves. Essentially turning thought into action.

I really like data-driven health and it's been a really big part of my life over the last few years. There is something about graphing the body that really appeals to me, so when I discovered Neurosity I was extremely excited about being selected for the first round of devices released.

The Notion has APIs that allow you to interact with your device and receive all the data from it. I thought a good first experiment would be to wear the Notion while I'm at my computer working and try to figure out when I'm most focused. This seemed like a good first run as I plan to do a lot of experiments around focus and how different factors can affect it.

In this post I'll talk about setting up and recording the data, and in the next post I'll cover reading the data and visualizing it!

Creating the Project

Because I want to visualize this data I decided to spin up a new React app using create-react-app. I also knew that I would need to store the data from the headset so that I could read it back out later when I wanted to visualize it. For that part I set up a GraphQL API with [Amplify](I set up a GraphQL API with Amplify and AWS AppSync via the Amplify CLI.

Setting Up the Infrastructure

To record the data :

To set up my app and GraphQL API, I ran the following commands:

npx create-react-app visualizing-focus
amplify init
amplify add api

I also created a DynamoDB table by using the @model directive in my GraphQL schema during API set up, like so:

type FocusDataPoint @model {
  id: ID!
  timestamp: String!
  value: Float!
}

Not only is a table created, but all the queries and mutations needed to perform CRUD operations on this data point were created in AppSync for me and the CLI generated those queries, mutations, and subscriptions for me for use in my app and Node script.

For more on creating GraphQL APIs with Amplify and AppSync, check out the docs!

Once I had the infrastructure in place it was time to create a script to run during the day to record the data coming out of the Notion.

Creating the Tracking Script

All that I needed to start tracking my focus was a small NodeJS script that would listen for the focus events coming out of my Notion headset and send them to AppSync. It took less than 70 lines of code in total.

// in src/track-focus.js

// Get deviceId, email, and password for Notion login
require("dotenv").config();

// polyfill fetch for node env
const fetch = require("node-fetch");
global.fetch = fetch;
global.navigator = {};

const { Notion } = require("@neurosity/notion");
const AWSAppSyncClient = require("aws-appsync").default;
const gql = require("graphql-tag");

// get all config
const amplifyConfig = require("./aws-exports").default;
const deviceId = process.env.DEVICE_ID || "";
const email = process.env.EMAIL || "";
const password = process.env.PASSWORD || "";

// set up Notion
const mind = new Notion({
  deviceId
});

// set up client to send data to AppSync
const client = new AWSAppSyncClient({
  disableOffline: true,
  url: amplifyConfig.aws_appsync_graphqlEndpoint,
  region: amplifyConfig.aws_appsync_region,
  auth: {
    type: amplifyConfig.aws_appsync_authenticationType,
    apiKey: amplifyConfig.aws_appsync_apiKey
  }
});

// copy the mutation out of the generated graphql operations created by Amplify CLI
const mutation = gql(`mutation CreateFocusDataPoint($input: CreateFocusDataPointInput!) {
    createFocusDataPoint(input: $input) {
      id
      value
      timestamp
    }
  }
`);

client.hydrated().then(async () => {
  // login to Neurosity
  await mind.login({ email, password });

  // listen for focus events
  mind.focus().subscribe(async focus => {
    // { probability: 0.51, metric: "awareness", label: "focus", timestamp:  1569961321102 }
    console.log(focus);
    try {
      const result = await client.mutate({
        mutation,
        variables: {
          input: {
            value: focus.probability,
            timestamp: focus.timestamp
          }
        }
      });

      console.log(result);
    } catch (error) {
      console.log(error);
    }
  });
});

First I set up the API client and Notion SDK and then set up the listener for focus events coming from the headset. Now whenever I sit down to work, I can turn on the Notion, run this script, and all the data will be collected for me and stored in the cloud.

We can verify that the data is being stored by running a query in the AppSync console.

Now all that's left is to record some data! Stay tuned for the second part of this series where I build out the frontend and data visualizations!

Amplify at Scale - Beyond the First Users

Kurt Kemple — Mon, 06 Jan 2020 15:24:34 +0000

I want to take a second to talk about why Amplify exists, the problem it's solving, and what that can mean for scale.

At the end of the day the goal should be to focus as much time as possible on producing product, no matter what that is. Which means we need to automate or abstract away anything we can. The closer to the surface you can work on something, the less time you spend working on things that are not the actual product or service itself.

A great example of this is the No Code revolution. Services like Webflow and Draftbit are abstracting the need to know how to code to make beautiful and engaging websites and mobile applications. However, there are times when you need to do more than what you currently can do with a No Code solution. That's where Low Code solutions step in to pick up the slack.

A Low Code solution is a tool/framework/etc that allows you to focus as much as possible on business logic and spend minimal time working on technical code, or code that isn't actually solving a business problem. Things like setting up APIs and authentication, or setting up data management on the client are technical code. It's very important, but isn't a feature itself, just the technological choices backing them.

Something that falls under this category would be GatsbyJS. If you're unfamiliar, Gatsby is an OSS framework that allows you to build really performant and compliant websites and apps by abstracting away the messy complexity behind an API that focuses on having a small surface but being flexible enough to get really deep under the hood.

Even if you have very little experience with Gatsby you can get started by creating a file in a directory and it will magically show up on your website, with all the best practices already baked in. You have to actively work against Gatsby to build a poorly performing app.

Given it's flexible API, you can also really get into the nitty gritty. You can do all kinds of things, like adding dynamic sections to your site, building pages programmatically, and even pull from an eco-system of plugins that do way more. Gatsby is by no means the only one doing this. There are hundreds of tools and frameworks all working at making it easier to do something, but the tools I want to talk about today are the ones that are making it possible to build robust applications using a framework like Gatsby by providing the infrastructure needed to support your application.

However, tools that offer this type of experience often fail to scale once you move beyond the basics, making it impossible to grow without removing the tool that allowed you the speed you needed to get to growth in the first place. The reason is that the comfort they offer often limits the flexibility. It's not easy to do what Gatsby does and allow for that progressive disclosure of complexity (if you're unfamiliar with that terminology Jason Lengstorf wrote a great article about it here).

These are services like Firebase, Netlify, and Amplify. Any one of these provides some combination of authentication, serverless functions, APIs, data and file storage, and even some things like machine learning services. All targeted at making it possible to build on top of cloud environments, while using best practices, without having to manage all the complexity yourself. However, the question with these types of services always is, will I outgrow it?

Scaling with Amplify

When we talk about scale in regard to a toolset like Amplify, we're actually talking about two types of scale. Scaling to accommodate more users (a great user experience), and scaling to accommodate more developers working on the product (a great developer experience). So when we ask the question, does Amplify scale, it's important to think of both the UX and DX, because both need to scale in order to be usable beyond the first users.

Scaling the Developer Experience

"Great things in business are never done by one person; they're done by a team of people." – Steve Jobs

While Amplify provides a great DX for the individual developer, DX isn't just about what's going on inside your code. It's also about sharing code across teams or an organization, working with environments for QA and feature development, where and how data is sourced to clients, or how the project is built and deployed. While most of these things are generally thought of as separate ideas or workflows, you can't ship efficiently if any of these pieces are not working or set up properly.

Providing a great developer experience may cause issues with scalability of services, and making services scale well generally adds complexity at the infrastructure layer, making the developer experience worse.

Things like serverless multiple this by allowing you to only write code that solves business problems by shifting all the complexity to the infrastructure layer. Development is about tradeoffs and we have to really know what tradeoffs we're making. This is why there are entire teams dedicated to solving this problem.

DevOps is a response to a need for better developer experience in cloud environments and cloud environments are a response to a need for better user experience.

Scaling Tooling

This tweet by @swyx really summarizes what makes a good DX for tooling:

// Detect dark theme var iframe = document.getElementById('tweet-1113478881086988288-795'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1113478881086988288&theme=dark" }

The Amplify CLI exemplifies a lot of these characteristics and I'd like to go over a few in particular:

Good defaults: When you use the Amplify CLI to configure AWS services, the CLI walks you through your options and always provides the opportunity to either use the current best practices defaults or allows you to configure yourself (there's that progressive disclosure of complexity). This allows you to do things like set up authentication that is enterprise ready in a matter of minutes without having to be a security expert.

Incrementally adoptable: Don't want to use Amplify for everything? Cool, just pick a category and start there! Amplify uses categories to break logic up into common workflows or scenarios that developers face when creating any product. You can incrementally add as many categories as you want. Some popular categories are:

Authentication (Federated, LDAP, etc)
API (REST and GraphQL supported)
Analytics
Storage (File storage or data)
Functions (Serverless functions with Lambda)
Predictions (Machine Learning and Artificial Intelligence)

Small API/config surface area: Amplify CLI only has a few base commands and requires no config from you. It may ask a few questions to help you select the proper options, but it generates the necessary config. At the end of the day the CLI is really a codegen tool, whether it's generating CloudFormation templates (responsible for what services get created and how they interact), types (Flow or Typescript), or GraphQL operations (queries, mutations, subscriptions), it eliminates a lot of boilerplate code that would otherwise be needed.

Learn once and reuse forever: The Amplify CLI's small surface area and repeated patterns make it intuitive to use for any category once you learn the basics of the CLI.

Remembers and adapts to you: One of the best features of the CLI is how it's aware of the current Amplify configuration and can generate the necessary config to tie together services. This is one of the hardest parts for most developers to understand about AWS, and the Amplify CLI handles this for you. If you add authentication and then want to add an API, Amplify will set up the proper permissions between the services. Also, when it comes to adaption, the CLI's plugin based architecture makes it possible for DevOps teams to extend the functionality of the CLI by creating custom in-house plugins. Allowing them to add categories or workflows for other AWS services, or even other cloud providers. You can find out more about the plugin system here.

The CLI does a lot more than this, but these are a few of the key features that allow the tooling to scale to handle any needs and any number of developers. Learn more about the CLI here.

Scaling Collaboration

When it comes to a good DX, collaboration is a must. Unless you're a sole developer working on a project (and even then you most likely don't work completely in isolation) than you are going to want to use tools and services that make it easy to share/show/ship products. The Amplify framework provides a number of features that make collaboration not only possible, but pretty darn enjoyable. Here's a few of my faves:

Git like workflow for CLI: It's not uncommon to want to set up specific environments of your system. Whether it's for testing or feature development, generally not everything is done in same environment that your users use. There may be a QA env, a staging env, or maybe a new environment is created for each bit of work done. Amplify supports all of these workflows with multiple environments. By using commands similar to git, you can create, push, and pull environments like you can with git branches.

Ephemeral environments: While we're talking about environments, having the ability to recreate them on the fly is invaluable. As your team and projects grow, generally so will the environment around it. Being able to easily recreate them opens the door to some really efficient workflows. A very common workflow I see is branched based deployments. Branch based deployments is when you deploy a new environment for each branch pushed to whatever git provider you are using. You do this via Amplify Console which is a hosting service for fullstack serverless web apps. This makes it easy to create isolated environments for testing, previewing, or sharing with other developers. When your infrastructure is easily repeatable it can scale to accommodate any number of new collaborators.

Deploy previews: It's hard to talk about collaboration without talking about pull requests. Pull requests are the epicenter of a project and it's generally where the most collaboration takes place. When I was at Major League Soccer everyone from product, QA, and design would all collaborate around pull requests and whether it was a web app or mobile app, we all wanted to be able to be able to preview the environment. The most efficient way to do this was to have a deployment preview linked in the PR itself. Now we had to set this up ourselves but it was definitely worth the work because of how efficient it was.

If you're curious about deploy previews with Amplify Console give me a follow as I'll be writing about it very soon!

Starters and sharing config: Because we can create these environments based off of CloudFormation templates generated by the Amplify CLI, we're able to share configuration across an organization if needed. Complete starters can be created and deployed to Amplify Console in a matter of minutes with the Deploy to Amplify Console button. If you're an agency that regularly builds e-commerce sites for clients, you can set up a default template that teams can use as a starting point for each project. They can then add any other functionality they need on top of the starter in their own environment. It's also possible to pull down existing config for an Amplify project from Amplify Console, much like pulling a remote branch with git.

Scaling Infrastructure

Until recently it was really difficult to take advantage of the recent developments in cloud and serverless computing. Without have a team of seasoned devops engineers or outsourcing that work it was nearly impossible to create the right configuration to scale well. Entire companies exist just to help you optimize your infrastructure configuration, making sure you don't waste money on unneeded resources, or worse that you aren't scaling properly to meet the demands of your customers.

However, as serverless and cloud move more into the commodity phase there has been a lot of progress on the user experience around serverless and cloud computing. Nader Dabit sums it up well in the following tweet:

// Detect dark theme var iframe = document.getElementById('tweet-1212497443805442049-926'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1212497443805442049&theme=dark" }

It's now possible to take advantage of serverless without being a master of cloud engineering and developers further up the stack are starting to build cloud based products on top of serverless. By using Amplify you get to take advantage of best practices when it comes to managing your infrastructure on AWS without having to know how to set it up yourself. Let's take a look at a few of the ways Amplify can help you scale.

Backend Infrastructure

Infrastructure based on data needs: When you use Amplify to create your GraphQL APIs you can specify what data should be stored via the @model directive in your GraphQL schema. This allows you to only create the storage needed at that exact moment. You can easily update this at any time by changing the schema. More info here.

Enterprise ready services: Amplify itself isn't a service, it creates the underlying CloudFormation templates needed to spin up the AWS services needed to complete that workflow. If setting up an API this could involve Amazon Cognito for authentication, AppSync for querying data, and DynamoDB for data storage. All of these services are relied on by enterprise level companies that need enterprise level services to ensure that their customers needs are always met. By using Amplify you get to use those same services without having to handle them yourself.

API performance: AppSync provides built-in server-side caching capabilities for any supported data source, improving the performance of latency-sensitive and high-throughput applications and allowing developers to fetch data from a fast, in-memory, managed cache, delivering data at low latency. As well as enhancements to GraphQL real-time subscriptions with pure WebSockets supporting a higher maximum payload size (240kb vs. 128kb with MQTT over WebSockets), enhanced connection and broadcast rates to effortlessly scale to millions of connections, CloudWatch metrics, and selection set filtering for GraphQL subscriptions. Check out this link for more info.

Serverless functions: Need to do some computing outside of CRUD operations? No worries, by connecting serverless functions to your API (or using via events or a REST endpoint) you can scale workloads infinitely. Need to create thousands of thumbnails as images are uploaded to your new e-commerce platform? Lambda can handle that and pretty much anything else.

Frontend Infrastructure

DataStore for Client Performance: When we think of infrastructure we generally think of backend services. But what about the network layer on device? Amplify DataStore provides a persistent on-device storage repository for you to write, read, and observe changes to data if you are online or offline, and seamlessly sync to the cloud as well as across devices.

Custom components and multi-platform support: Amplify also has pre-built components for most front-end frameworks and platforms that allow you to quickly connect to your backing infrastructure without having to manually set up anything. Display S3 files or handle uploads with the Picker component, set up entire auth flows without having to write any backing logic, or present a UI for interacting with chatbots. All of these components are plug-and-play, saving you countless hours or even weeks of development time.

Conclusion

While I've covered some of the more key features here it's important to note that I've really only scratched the surface in ways that Amplify can help you scale, both from a DX and infrastructure point of view. If you're curious about how else Amplify can help you get your product in production then I highly recommend taking a look at the docs!

Everything Serverless Functions in AWS Amplify - Part 3

Kurt Kemple — Thu, 12 Sep 2019 23:56:22 +0000

In this episode we dive into using a serverless function to handle multiple graphql resolvers as well as interact with a DynamoDB table set up with the Amplify CLI. Also, instead of using amplify mock in this episode we use the AppSync console.

Links from video:

Article No Longer Available

DynamoDB JavaScript Docs

Transcripts:

Transcripts coming soon. Moving to a new service.

Everything Serverless Functions in AWS Amplify - Part 2

Kurt Kemple — Thu, 05 Sep 2019 23:33:19 +0000

In the second video we go deeper with serverless functions being used as resolvers in AppSync. We take a look at accessing arguments being passed to the function, as well as how to access sibling data in the resolver and how to handle pagination. We did all using the "amplify mock" command and running the environment locally.

Links from video:

Everything Serverless Functions in AWS Amplify - Part 1

Transcripts:

0:09

Hello, everyone, and welcome back to everything service functions in AWS amplify. Yeah. So last week, where we left off, we had created a react app added amplify to it, set up a very basic graph QL API using App sync. And here's the schema. We just made a Hello World function, which we connected to a server list function. And yeah, so that returned, essentially. So it actually looked a little bit more like this.

0:46

Yeah, just like that. And yeah, so we just made a function that could return hello world, and we checked it in the browser, and everything was great or great. So if you haven't actually seen that, there'll be a link o the first one, so I definitely recommend checking it out. But where we're going to pick up today is we're going to work with this function.

1:09

And we're going to extend the capabilities of it. And then we're going to change, we're going to add another function and pull some data in from an API. And so maybe, you know, we'll see how far we get and when it feels like a good stopping point. But yeah, so basically, now that we know how to set up a service function, like we did in part one, we're going to see all the different type of things that you can do with it. So should be pretty interesting.

1:37

And, yeah, let's go ahead and dive in. So the first thing that I'm actually going to do is we don't really need the UI at this point. So we're deciding what the schema is going to look like, you know, the data structures and at this point, you know, checking that in the UI seems like a lot like a pretty slow feedback loop.

2:00

We also don't want to be deploying things out to AWS. And what I mentioned in the last episode is that we would use something called mock to go ahead and mock out the API, and data storage and all that fun stuff. And that's exactly what we are going to do. So first thing I'm going to do is run, amplify my.

2:21

And so this is going to spin up a server, but it's going to be local, but you can interact with it, and it will behave exactly as if it was deployed on AWS. So the cool thing is, you can see that there's mock endpoint running, which is just the IP from my machine, so localhost:20002. So I'm going to go ahead and open that up, and I've just configured browser preview to have that as the default. So now I can just slide this over a little bit. You know, we can hide and show the Explorer for more room. But now we have graphical rights.

3:00

So we can, we can see our query here. And then we have the server list function that it's connected to called hello world. So given this schema, it should return a string. And then that string should come from the function. So this should return hello world. So I'm just going to close the Explorer here and get rid of this. And oops, let's run the query.

Hello, world.

3:35

So we run it and we get data back and hello world. And sure enough, it's hello world. And so this is just local running on my machine. And so it's pretty cool. So to test this to see it's like essentially doing like, a hot reloading thing. We could change this to Hello universe. We save it, we rerun the query, and look at that Hello universe. So it's pretty cool. You can work with

4:00

These lambda functions locally and you know, just spin up graphical. And you get this kind of really quick feedback loop that's, you know, just allows you to essentially work a lot quicker, right, which is awesome. So one thing though is like if we want to change the schema, because graphical is doing schema introspection to figure out what's available, then in that case, we have to reload graphical, but I think I can live with that, right? So let's add a parameter for message will make it optional, and will make it a string. And so will still return a string, and we'll still call this function. So now we're passing an argument to this query, right? We want to do something specific based on a bit of data.

4:46

So how do we handle that in our lambda functions? So the way lambda functions get is it gets something called an event. And so essentially, what's happening is because it's in a pipeline, it's connected to App sync, this event gets populated for you. And everything is, you know, mapped to the event from things so like with when it's attached to this lambda function, it's attached to sorry, like a field in your graph QL schema, it knows like, okay, so if any arguments come through all attach those, and we'll take a look at how you can also access like the sibling data, just like you would in any other graph. QL project, right? Like sometimes maybe you want to grab, you know, related data, to then do something more augmented, like, take latitude and longitude and return in a dress or vice versa, right, you have a full address. So you take that and you return a latitude or longitude.

5:32
There's a multitude of use cases. So okay, so we have our event. So what we can say here is everything comes in here. Use the event and event data to see what our arguments are and so everything comes off under event arguments, right. So this is like would store any type of argument that's passed. So here we have message so we can expect event to argument stop message. Well, we can't expect it because not required, but it should be there should be something available if it is passed in.

6:24

So we can say message equals event arguments. That message or you know, you could do structure you can do whatever you want. And then here we'll just say, message. If not, hello, universe actually will leave that Hello universe. Okay, so we'll save this but now remember, we change the schema. So if I just come over here and I'm like, ah, message, ah, see, it's gonna yell at us and say, Hey, we don't know what messages right say. So we got this unknown argument. So we got

7:00

And essentially, we run our query. So we could have copied it out. But it's pretty small. But now we've got message. So it should return Hello universal, let's do hello world. It will run this a hello world. So let's remove that, right. And so if we go back and we look at this function, it should return Hello universe. So let's run it. And we get Hello universe. So that's how you can handle arguments. So pretty cool.

7:40

Okay, so we've taken a look at how we can now use arguments and pass data. So we're going to set up a new function, and we're going to use that function to call an API, and we're going to look at using some arguments to handle pagination. So I'm going to add a new property here.

8:00

So, in our list Pokemon, we are going to want to be able to set a limit. It's not required though. And also were to pick up from when we left off. And so we're going to call this next token. and in this situation, next token will be an int.

8:33

And this is going to return a oops, sorry, it's not gonna it's going to return a Pokemon connection.

8:46

And so what that means is because when we return it, because it's a list and we want pagination, we need a way to identify Hey, what was the last item that was given?

9:00

Like, or, you know, or where am I in this list of Pokemon. So when you get a response from this, what you really want is the items, the actual Pokemon, but as well as that token that next token, so it's kind of like an intermediary layer, instead of just returning the array of Pokemon. We also want that next token. So we have a type Pokemon connection, which has a next token, which is a string, and it's not, or sorry, in this case, it's an event. And it's not required because it could be not. And if it's no, that means Hey, you're at the end, there is no next token, you've hit the end. And then we want items. And so items and for brevity sake, it's not going to be too much, but it will be Pokemon.

9:46

But we have to create a type for that. So I am going to fast forward through the creation of this pokemon type, and then we'll pick back up

10:04

Okay, we've created a Pokemon connection, a Pokemon type and a Pokemon move. So the first thing that we want to do is set up a function to do the listing of the Pokemon. So say function name. And we'll have to name this will call this ES for everything server lists.

10:34

Actually no dashes just Pokemon. And then of course, we want to do dash environment. So that one is created for any environment that we have, it can be in. Okay, so we're just we're going to stick for this now, and Pokemon moves are not required just yet. So we're not going to worry about these at the moment but we are going to worry about listing the Pokemon

11:01

So what we're going to do here is run amplified function. So if you look down here in the terminal, it says, actually, let me pull that up one, just that go. Well, okay, so it says, please run amplify add function. So it's already telling us like, Hey, you added a function, but it does not exist. So let's make that exist. So we're going to say, amplify add function.

11:33

Okay, and for a name, we will call this the same thing. Yes, lyst Pokemon, or for the label, and then for the lambda function name will keep it the same. We want a Hello World function. So I'm going to pick that.

11:51

In this case, we do not want to access any other resources. We're going to access a third party API

11:59

Want to edit the local lambda function now? Yeah, we definitely do. So we're going to hit yes.

12:07

Okay, so here we have shiny function, but we are going to want to fetch some data, right we want to get we want to get some Pokemon, and we need to take into account that we might get a limit. So we need to pay attention to that. And we might also receive a next token. So

12:31

I'm going to go and get the URL for Pokemon. Okay, so coming back in here, yeah, build Pokemon URL, it's going to be a function that takes a limit and the next token and it going to return a string. And so this is the base URL for Pokemon and already know that it takes two parameters that are important. And that is limit. And next token, or sorry, the API takes limit and offset. And that's how you could do pagination. So for us, this is a pretty easy conversion. So we just say limit. And that's going to be equal to what is passed in his love it, and then we're going to have offset. And that is going to be equal to whatever is passed in as next token. So that's as easy as it is to kind of get this pagination going.

13:44

Okay, so we know that we want this URL. Now we need a limit. And we need a next token. So let's go ahead and get those. So we're going to say const limit. And we're going to say equals here and we'll do 20. It's going to be a default, because we might not get it. And then we're going to look for next token, and that's also going to be are going to have a default of zero. So that's our offset, so we don't get an X token we're starting from the beginning. And if we don't get a limit, then we're doing 20 at a time increments and that's going to be equal to event arguments.

14:38

Okay, so now we have that and we have a URL. So what we want to do, I'm just going to give this a little bit more room. We need to like fetch this data, we need to get it some way so I'm familiar with x iOS, which is not installed yet. We will install it and we're going to say get URL. And so now we're doing some basic stuff. So this is pretty cool. Let's g is equal to x Yes Get URL because that returns us promise. And we'll do a try catch here in a second.

15:26

So now we have the result. So what we want to return So remember, this is listing Pokemon. But if we come back to the schema, it's a connection. So we need to form a connection, not just return the items themselves, and we want an ID and a name. So we have to get that. So let's do this. We will say that the response is equal to. So first, let's take care of our next token, which will, we would want to check our result list and see if we're at the end. But for now, let's just do it as limit plus.

16:21

Next token, right? So wherever we started from plus what we fetched, we'll just treat that as the default, just for now to return something. And then we will say, items, is equal to I want to say result data. I think that's correct. I'm going to check the API docs and I'll be right back.

16:51

Okay, so I checked the docs and it looks like it's going to be result data results and

17:00

For our next token, so remember, we want to return this if we have more results. But what if we don't? What if this is the end so we can say, result data. Next, because that is returned if as a URL if there is more, if you can fetch more. So if we want that, if we if we know there's a next than we can just assume that will get more.

17:27

Otherwise, there's no next that we return no for a token.

17:32

So now in this function, we don't want to return this. We want to return our response that is formatted in the data structure of a connection. But right now, we are handling Oh, look, I'm person missing, in a way. I wonder how many of you saw this and we're like, oh, you're missing away. It's kind of break.

17:53

Yeah, so Okay, so we have some a sickness going on, but we're not catching any errors. So

18:00

Let's try and catch them.

18:04

I should just let prettier do that.

18:07

All right, catch. error

18:11

we will first will console log it

18:18

for funsies, but also console.log it. Oh, and we didn't return our response. So we will I context done that error. So if you hit an error, that's kind of the first parameter, this up here because used to be in that, that's looking a lot better. Okay, so we get our limits. All that looks good. So should should be good. We should be good to go here. So we're gonna hit Continue. All right, let's, uh, let's spin it up.

18:52

Okay, so because of the way the API is structured, we can't actually get back the ID that doesn't come back with the results. So when you list the resources, all it really gives you is the name and the URL to actually fetch that Pokemon. So what we're going to do is we're going to fetch them real quick. So we'll say cause.

19:35

So let's actually, so we have the name. So let's add back those, those properties.

19:42

Let's add ID back and see if this in fact, is working, which is I believe an event.

19:51

Save that. We want the items ID and Name and let's run it. So there we have everything.

20:00

And now the Pokemon API, I would imagine their caches pretty warmed up, but we get the ID of the the Pokemon were before we could not. So now we have the moves, which is a Pokemon move. And so we have a name, property and power, accuracy and priority. So what I'm actually going to do is create a new property called stats. And this is going to return Pokemon stats.

20:30

But it's going to be powered by a function.

20:34

And this function, its name will be will call it ES.

20:40

Pokemon stats. And again, we need to specify for the environment. So

20:49

what we're actually going to do here is take these out.

20:52

We're going to create a new type

20:57

and we'll call this pokemon stats.

21:04

Okay, so we have to do two things in order to make this work first right now, we are not as well, we have to add a function. So technically we have to do three things. But the The first thing, let's actually just remove this declaration for right now. don't even need that. Okay, sorry. Yeah, so we'll do this. So we don't have to create a new function

21:24

just yet, but still, we can't get the name. So right now we're not returning any moves. We're not doing any anything deep. we fetch the Pokemon, but we don't have the moves.

21:44

Hey, cool. All right. Thanks for sticking with me. So we got the name. So now, we want the deets, right, like whenever. Maybe we want to access stats about this. So we need Pokemon stats and we

22:00

We need this to be

22:03

function, right? Like we need to get that and also how we're going to get it. We're going to query the API using the name or a source property, like a sibling property to stats. So we'll see how not only can you pull data in as an argument, but you can also access the sibling data of the field that the lambda function is resolving to. Okay, so we'll save that and then we're going to get notified, it's gonna say, hey, you need a function. So let's go ahead and create that function. So here we're going back up to the root, I got it. And we're going to say amplify add function.

22:48

Okay, for the name of it, we will call it espokemonstats

23:01

Hello World function, we do not want to access other resources. And we'll get into that in a later episode.

23:08

Yeah, we definitely want to edit it now, though.

23:13

Cool. So what I'm actually going to do is we're going to use

23:19

decent amount of this stuff. So we're going to just bring it all over into our new function.

23:27

And we're going to change the thing. So first,

23:30

this won't be here. So what will be here will be name and that won't come off of that the arguments it will come off of event source. And so the source is

23:47

the sources is the sibling data, right? So, in this case for moves, next that will have stats it's the name right we want the name. So now we'll say we'll just keep it build Pokemon

24:00

URL, but instead it's going to take a name. And so appear it's going to take a name.

24:07

And we're not going to be calling Pokemon, we're going to be calling

24:12

moves. And I believe instead of having any of this, we just do slash and then name.

24:24

So I'm going to verify that really quick. On the docs.

24:29

Move. This is not news. It's move. That make sense. Okay, so now we have that we have our URL. So we're going to build our results. We won't need

24:40

all of this data and our response doesn't need a next token, and the three properties that were accessing priority, let's go to actually see what those are.

24:54

Yeah, so we have power, accuracy and priority those are root properties on the

25:00

But just so that we can see will say contest,

25:06

power,

25:08

accuracy,

25:10

and the other one

25:12

priority.

25:15

And those are going to be equal to result data.

25:23

And that's what we're going to respond with.

25:29

So we could just pass result data, but I just want to show that these properties do in fact, come off of there. And we're returning them exactly because it's graph QL. And since the only three data fields that we say are available, are those three it would only like return those three to the end user. But we're just going to explicitly spread it out so that you can see,

25:53

I said our limit to five

25:57

the name moves the

26:00

Name and all the stats. All right.

26:07

Okay, so if we close this up, we can see, for sword dance, we got no, which is interesting. Maybe we hit a four or four

26:18

on there, but we can see that we are getting the stats back for most of these moves. But that's interesting. So here is another one. I guess it's another evolution of the same one. But yeah, so that's that just seems to be missing. But yeah, so we've got our data coming back. So now we have, if we go back to our schema, we have three functions.

26:42

And we've done a lot of things. So first, we've allowed to pass arguments. We've set up how to deal with pagination based on arguments. And lastly, how to access the sibling data on on service functions that might be buried within

27:00

Your schema and aren't at the root of query. So I hope this was fun and enjoyable and I will see you in the next one.

Transcribed by https://otter.ai

Introducing Pokedex

Kurt Kemple — Sat, 31 Aug 2019 20:41:02 +0000

Deploy a full stack Pokédex app backed by AWS AppSync and AWS Lambda in minutes.

I recently asked what examples people would like to see next and the biggest request by far was how to handle pagination in AWS Amplify and AWS AppSync and what better way to showcase that than with Pokémon!

What It Does

🦊 Scroll through 100s of Pokemon
💅 Animations
📄 Pagination
🔥 Serverless back end
🚀 GraphQL
💻 Deploy back end in minutes

How It Works

The code for the app is located here.

This project uses AWS AppSync to provide a serverless GraphQL API that is backed by serverless functions. These functions are used to interact with the Pokemon API.

In the project, you'll notice a folder named amplify. This folder contains the back end for the app that can be redeployed in anyone's account. In the amplify folder you'll see a backend folder. In this folder you'll see the configuration for the three main features:

GraphQL API (built with AWS AppSync)
Function (built with AWS Lambda)

In the backend/api folder you'll see the GraphQL API configuration as well as the base GraphQL Schema.

This is the base GraphQL Schema. You'll see that the base schema looks like this:

type Query {
  listPokemon(limit: Int, nextToken: Int): PokemonConnection
    @function(name: "listpokemon-${env}")
  pokemon(id: Int): Pokemon @function(name: "getpokemon-${env}")
}

type PokemonConnection {
  nextToken: Int
  items: [Pokemon]
}

type Pokemon {
  abilities: [PokemonAbility]!
  baseExp: Int!
  height: Int!
  id: Int!
  image: String!
  moves: [PokemonMove]!
  name: String!
  weight: Int!
}

type PokemonMove {
  id: String!
  details: PokemonMoveDetails @function(name: "pokemonmovedetails-${env}")
}

type PokemonAbility {
  id: String!
  details: PokemonAbilityDetails @function(name: "pokemonabilitydetails-${env}")
}

type PokemonMoveDetails {
  name: String!
  flavorText: String!
  effect: String!
}

type PokemonAbilityDetails {
  name: String!
  effect: String!
}

If you've never worked with Amplify before you may not be aware of the @function directive. This is part of the GraphQL Transform library of the Amplify CLI.

@function - Decorate any field with this directive to use a serverless function as an AppSync resolver. These map to the functions configured via the Amplify CLI.

Deploy the App

Deploy the back end and run the app

Clone the repo & install the dependencies

~ git clone https://github.com/kkemple/pokedex.git
~ cd pokedex
~ npm install

Initialize the Amplify project

~ amplify init
? Enter a name for the environment: dev (or whatever you would like to call this env)
? Choose your default editor: <YOUR_EDITOR_OF_CHOICE>
? Do you want to use an AWS profile? Y

Mock the backend to ensure app is working properly

amplify mock

Start the app and verify UI is working properly

~ expo start

Push to AWS

~ amplify push
? Are you sure you want to continue? Y
? Do you want to generate code for your newly created GraphQL API? N
> We already have the GraphQL code generated for this project, so generating it here is not necessary.

Customizing the GraphQL schema

This schema can be edited. If you need additional fields or base types, you can update the backend by doing the following:

Update the schema (located at amplify/backend/api/gweatherapp/schema.graphql).

Redeploy the back end

amplify push

There is a settings page in the app, a fun challenge would be to allow users to store locations and set one for the forecast!

If you or anyone you know needs help getting up and running with this app, reach out to me on Twitter, I'd be happy to help!

Introducing Gweather - A Micro Weather App with Gifs!

Kurt Kemple — Fri, 30 Aug 2019 13:10:51 +0000

Deploy a full stack app that gives you realtime weather updates with style.

I've received a lot of feedback about how the previous app examples I built were great for learning AWS Amplify because it shows how all the pieces come together to make an actual app. With that in mind I decided to show off one of my favorite features of Amplify which is backing your GraphQL resolvers with serverless functions. This allows you to use just about anything as a data source and is a such a powerful feature!

What It Does

Gweather is a micro weather app and provides features like:

🌎 Uses geolocation to get weather data
⛈ Micro weather updates
🌠 Weather related Giphy images
👮‍ Authenticated
🔥 Serverless back end
🚀 GraphQL
💻 Deploy back end in minutes

How It Works

The code for the app is located here.

This project uses AWS AppSync to provide a serverless GraphQL api that is backed by a serverless function that fetches the weather and gif data.

Authentication service (powered by Amazon Cognito)
GraphQL API (built with AWS AppSync)
Function (built with AWS Lambda)

In the backend/api folder you'll see the GraphQL API configuration as well as the base GraphQL Schema.

This is the base GraphQL Schema. You'll see that the base schema looks like this:

type Query {
  weather(lat: Float!, lon: Float!): Weather
    @function(name: "getweather-${env}")
}

type Weather {
  timezone: String
  current: WeatherSummary!
  hourly: WeatherSummary!
  weekly: WeatherSummary!
  icon: String!
  temperature: Int!
  feelsLike: Int!
  gif: String!
}

type WeatherSummary {
  summary: String!
  icon: String!
}

If you've never worked with Amplify before you may not be aware of the @function directive. This is part of the GraphQL Transform library of the Amplify CLI.

@function - Decorate any field with this directive to use a serverless function as an AppSync resolver.

Deploy the App

In order to run the app you will need an API key for both the Giphy API and the Dark Sky API. Both have a free plan that should be more than enough to run this app.

Deploy the back end and run the app

Clone the repo & install the dependencies

~ git clone https://github.com/kkemple/qweather.git
~ cd gweather
~ npm install

Update the serverless function with your Dark Sky API and Giphy API keys in amplify/backend/function/getweather/src/index.js

const buildDarkSkyUrl = (lat, lon) =>
  `https://api.darksky.net/forecast/[key]/${lat},${lon}`;

const buildGiphyUrl = tag =>
  encodeURI(
    `https://api.giphy.com/v1/gifs/random?api_key=[key]S&tag=${tag}&rating=G`
  );

Initialize the Amplify project

~ amplify init
? Enter a name for the environment: dev (or whatever you would like to call this env)
? Choose your default editor: <YOUR_EDITOR_OF_CHOICE>
? Do you want to use an AWS profile? Y

Mock the backend to ensure app is working properly

amplify mock

Start the app

~ expo start

Push to AWS

~ amplify push
? Are you sure you want to continue? Y
? Do you want to generate code for your newly created GraphQL API? N
> We already have the GraphQL code generated for this project, so generating it here is not necessary.

Customizing the GraphQL schema

This schema can be edited. If you need additional fields or base types, you can update the backend by doing the following:

Update the schema (located at amplify/backend/api/gweatherapp/schema.graphql).

Redeploy the back end

amplify push

There is a settings page in the app, a fun challenge would be to allow users to store locations and set one for the forecast!

If you or anyone you know needs help getting up and running with this app, reach out to me on Twitter, I'd be happy to help!

Everything Serverless Functions in AWS Amplify - Part 1

Kurt Kemple — Thu, 29 Aug 2019 23:33:10 +0000

In this intro to the series I set up a new React project with create-react-app, configure AWS Amplify. Then I create a serverless function and access it via GraphQL with AWS AppSync.

Links from video:

Transcriptions:

Kurt Kemple 0:01
Hello, everyone, and thank you for joining me on the first episode of everything service functions with AWS amplify. Today we're going to take a look at setting up a basic server list function that says hello world, and putting it behind graph kill API with epic. And we won't do all this without leaving VS code. To do this, I'll just CD into my projects directory, and run and PEX create react. And we'll just call this Hello, world. Okay, so this is going to create the project install the dependencies I'm going to fast forward, I'll see you when it's done. Okay, so the project has completed, I've opened up the project in VS code, and I'm going to bring the terminal back up. Now that we have our project, our basic react app, the first thing that we're going to do is we're going to knit this as an amplify project.

Kurt Kemple 1:24

For the name will choose hello world. For the environment, I'll choose Dev. I will choose Visual Studio code editor, JavaScript for the project react. And it knows that this is a create reactor project. So it's just going to go ahead and give me those smart defaults. And lastly, is I have to use a profile. So if this is your first time using amplify, you may have been greeted with a request to configure amplify CLI.

Kurt Kemple 2:00

I'm going to put up an image of Nader Dabit's YouTube video that you can go and check out and here's the link as well. And this will walk you through configuration. It's also in the very beginning of the docs if you go to the Amplified docs here. But yeah, so now I'm going to fast forward while this runs, and I'll see you when it's done. Okay, so now that that's completed, let's go ahead and add an API.

For the type will choose graph QL, for the API name will stick with hello world will choose the API key, we're not going to require authentication to use the app, we do not have an annotated schema, so we're going to go ahead and create one. So we'll choose Yes. And here I'm going to do single object. And yes, we want to edit it now. So it opens up the schema. And what I'm going to do is I'm going to get rid of this to do model. And if you're unfamiliar, these directives, or graph QL, transforms, basically are what allow you to customize and create app sync graphical API's, but doing it through this schema, and then that gets deployed and it knows what you're trying to build. So we're actually going to get rid of this because we just want to do our hello world right now through a surplus function.

So we're actually going to say type of query. And hello world is going to be our query right? Now it's not going to take any arguments, it's going to return a string, that is a must. And then here, we're going to say function, because it's going to be backed by a function. We haven't created that yet. But we will next. So for name, we're going to say hello world, it's a lot of hello world stuff, right? But here's the thing. So because we're creating this with amplify, amplify supports multiple environments, meaning, if I created, we created Dev, but if I wanted something called like production or staging, we wouldn't want to necessarily use the same service function. So we can use this kind of variable here as to say, do one for Dev and one for production and one for each environment that we happen to create. So that's it. So this is our schema, we just use this one directive, you know, there's nothing else really crazy going on here. Yeah, and so we save that, and then we're going to press Continue.

Kurt Kemple 4:45

Okay, so what we missed here, essentially, is that the schema was created. So some of the next steps would be to push it or we're actually going to take a look at mocking, but first, we have to add our function.

Kurt Kemple 5:03
So we run amplify add function.

Kurt Kemple 5:12

So for the name, we said, it's going to be hello world, in our schema, so let's make sure we call it hello world. And here, we'll call that hello world. And this is going to just be a simple Hello World function. So we have some other options, right. So if we had storage setup, we could also do a credit function and access Dynamo DB table that we've created within this amplify project. Or if we just like, we're going to know we're going to build out maybe a couple different routes, or something like that, we could actually basically recreate a REST API full on REST API, but it would be service and backed by API gateway, and use Express. So like, you just be able to write you know, API doc get path and then handle those requests, like you were in an express up. For right now, we don't need all that.

So we're just going to stick with the Hello World function. Technically, no, we don't want to access other resources, graph QL will access it. But we don't need to like access graph QL from within the function or the user or anything like that. So we can hit know for now. And later in the series, we'll we'll take a look deeper into some of these options, because you can do some pretty powerful stuff. Yeah, let's let's edit it now, just so that we can kind of see what it looks like.

So you see here, we get lambda function. And it's just going to output hello world. Perfect. That's essentially exactly what we want. When it's console logging out here, is key. So like, if you look here, we have this event, JSON, and it has keys. So if this lambda function was to receive events like and not be being used through graph QL, you could receive leave it like that. And so that just means like that data to be there, we don't need this. So we're going to get rid of it. And that's it. This is our service function, so we can hit Continue. Alright, so that's all done. So now that we have it set up, let's run amplify mock, so we can test it out. So while this is spinning up, I'm going to go ahead and fast forward so that we can move on.

Kurt Kemple 7:27

So a graph QL code generation gets done for us, if we want to like this will generate all the query subscriptions, and mutations in our case, we just have a single query. So not much will be generated. But you can get it you know, just vanilla JS, you can get with TypeScript definitions. And with flow, so if you prefer types you can do that will stick with JavaScript for simplicity. So for the files, yeah, sure, it's just going to put it in a folder called craft QL, inside of directory where the rest of our code is. And you know, we want to generate all the mutation subscriptions. So here, you could specify and break down what you want to generate for, but we can just say yes, and then so this is the depth like, so if you've worked with graph QL, maybe a lot before you know that it can get expensive to access multiple layers, like say you have blog posts that have comments, you know, and then from like, comments, you have their authors, and you can get their blog posts and get those comments and like, so on and so forth. So you could just get like very expensive. So this just limits the amount of depth. So in this case, you can only go down two levels.

Okay, so our graphQL endpoints has been successfully set up and we are mocked. So theoretically, at this point, we can start querying, but we need to do this with the API key because we said to do that, so first, we're going to set up our client. And then we'll go ahead and update the React app to call the directory and or the the function and we'll take a look at that the result. So first, we're going to add the dependencies, which is AWS amplify, this holds the main amplify like object in all of the classes for the different categories.

So like for API, analytics, predictions, things like that. And then we're also going to add AWS amplify react. And this actually, we don't, we don't need this one yet, because we're not doing any off like that has like a bunch of pre built components. So if we were adding off, I like to use the pre built like authenticator, which gives you the whole sign in flow. completely done. You don't have to do anything, but we're just doing API key, so we won't need it. So we're just going to add amplify. And while that is installing, we're going to open up source. And there's two things I want to point out. One is this AWS exports file. And so this is actually where the base configuration is stored. And yeah, so what we need to do is configure amplify, and so the way that we do that, is we import amplify, from AWS amplify, and then we import the configs, it will call it Apple fi, config.

And that's going to come from that AWS exports file. And then we're going to configure will give it to amplify config. And that's all that it takes to actually configure it. And now, we actually want to use it right, we want to call this function. So today do that we're actually going to go into app JS. And we're going to do a few things. We're going to state and use effects.

Kurt Kemple 11:14

And we're also going to import API and graph QL operation from AWS amplify. So what we'll do here is we'll create state to store our message will just make it No, by default. And then we'll use an effect to go ahead and fetch that message.

Kurt Kemple 11:57

So now this would set our message. So let's come down here. And we'll say if a message, show message, otherwise, the default that was already there. So now we have this all set up. So we're going to go ahead. And actually, I need to open up the browser. And I'm going to do it within VS code. But I don't have that extension installed yet. So we're going to pause right here, I'm going to get that installed. And then we'll open up this project and run it.

And if everything is working, we'll have a serverless function. Okay, I've gotten browser preview installed. And I'm ready to open the project. But I've realized that we've used our query hello world, but we haven't actually defined it. So I want to take that opportunity to look over here into the folder and we see that we have source graph QL queries, and we open that up, we get hello world. So that was automatically generated for us, we didn't have to do it. So let's go ahead and import that.

Kurt Kemple 14:14

Okay, so now we're ready to run the project. Okay, so we've got our build. So let's do open preview and we get hello world. So our function was called. And we are now able to access this function through a graphical API. So once again, what we did was we use the API SDK essentially off of API, in random craft kill operation that was automatically generated for us, we set up a server list function. So since we we're mocking this, we can actually make changes in real time. So let's go ahead and change that. Let's say hello universe. Right. So we change that reload the page, hello universe. So now we can work with this locally change, get get the function working like we want just like as if we had pushed it had it hundred percent ready to go, and then deploy it to AWS. So it's just a much improved workflow. And so let's take a look.

Kurt Kemple 15:34

So to do that, we just control See, the next thing that we would want to do is run amplify, push, this would put the resources in AWS. And then if we restarted the app, we would actually be talking to production service. Instead, I'm not going to push it out yet, because even though we're doing this video, we're not done building out this this function or this graph kill API. So in the next video will take a look at adding dependencies to this lambda function, like using other MPM packages, and how we can handle parameters. And maybe we'll add something fun and fetch some actual data. Alright, thank you for joining me. I hope you enjoyed this, and I'll see you next week. Bye now.

Should interviewees be allowed to search for answers?

Kurt Kemple — Wed, 28 Aug 2019 18:08:51 +0000

I spoke with a colleague today about interviewing and we were both in agreement that not being able to look up answers/solutions to problems is not a good way to interview. Really takes away from the real-world experience of a developer. I wear out that Google search bar on a daily basis so why would we expect others to be able to recall information from their heads when it can easily be searched for.

On another note, should they be able to use pre-built solutions like libraries or frameworks to solve problems. Again, I'm of the yes attitude. Providing an existing solution is something we do all the time in our day-to-day jobs.

Can't wait to hear what you think!

Introducing Quick Notes

Kurt Kemple — Tue, 27 Aug 2019 22:50:48 +0000

Deploy a full stack web app to help you organize your notes when you're on the go.

The other day I released Journey, a bite sized app that helps you track your job listings when on the job hunt. I received a lot of positive feedback and figured I would put together some more examples of the types of things you can do with AWS Amplify and backing Amazon services.

That's why I built Quick Notes. It's a small enough app that it can be figured out relatively easily and it also serves a purpose that hopefully many will find useful, just like Journey.

What It Does

Quick notes allows you to quickly take down and access notes and provides features like:

🎙 Record notes
🔈 Play notes back
📖 Read notes
👮‍ Authenticated
🔥 Serverless back end
🚀 GraphQL
💻 Deploy back end in minutes

How It Works

The code for the app is located here.

This project uses Amazon ML services (Amazon Polly and Amazon Transcribe) and the Amplify Predictions category to convert text to speech for playing notes, and for converting recorded notes to text to store in AWS AppSync (GraphQL service).

Authentication service (powered by Amazon Cognito)
GraphQL API (built with AWS AppSync)
Speech To Text Generation (built with Amazon Transcribe)
Text to Speech Generation (built with Amazon Polly)

In the backend/api folder you'll see the GraphQL API configuration as well as the base GraphQL Schema.

This is the base GraphQL Schema. You'll see that the base schema looks like this:

type Note @model @auth(rules: [{ allow: owner }]) {
  id: ID!
  title: String!
  text: String!
  createdAt: String
  updatedAt: String
}

If you've never worked with Amplify before you may not be aware of the @model and @auth directive. These are part of the GraphQL Transform library of the Amplify CLI.

@model - Decorate any base type with this directive to get CRUD and list query and mutation definitions, a DynamoDB table, and resolvers created for the GraphQL operations.

@auth - Decorate any base type or field with this directive to get granular authentication and authorization set up for protected data.

Deploying the App

To automatically deploy the app, click the big orange button 👇

If you wish to manually deploy the app, follow the instructions below.

Deploy the back end and run the app

Clone the repo & install the dependencies

~ git clone https://github.com/kkemple/quick-notes.git
~ cd quick-notes
~ npm install

Initialize and deploy the Amplify project

~ amplify init
? Enter a name for the environment: dev (or whatever you would like to call this env)
? Choose your default editor: <YOUR_EDITOR_OF_CHOICE>
? Do you want to use an AWS profile? Y

~ amplify push
? Are you sure you want to continue? Y
? Do you want to generate code for your newly created GraphQL API? N
> We already have the GraphQL code generated for this project, so generating it here is not necessary.

Start the app and register a new user

~ yarn start

Deploy the front end

Create a new repository with your git service of choice
Push the project to your new repository

~ git remote add origin <your_new_repository>
~ git push --set-upstream master

Connect to AWS Amplify Console and wait for build to start. You will be given a production URL and you are ready to take some notes!

Customizing the GraphQL schema

This schema can be edited. If you need additional fields, you can update the backend by doing the following:

Update the schema (located at amplify/backend/api/quicknotes/schema.graphql).

Redeploy the back end

amplify push

If you or anyone you know needs help getting up and running with this app, reach out to me on Twitter, I'd be happy to help!