AWS Amplify Release, GraphQL, and Recent Curated Links

This release kicked off this week in time for re:Invent and I put together a quick write up. Any questions, feel free to ping me via my contact form or better yet, just pop a question at me via the Twitters @Adron.

Authenticator

Amplify’s new Authenticator

Docs here

The new authenticator is a component that adds a full authentication flow for your app with coordinated boilerplate. This covers vue.js, angular, and react frameworks. The component has a customizable UI (as you’d expect), includes social logins for Google, Facebook, Apple, and Amazon. The initial setup is zero-configuration, and does have password manager support, along with show/hide confirm password forms.

The zero configuration works based on your Amplify CLI setup. To use this component grab the latest version of Amplify 6.4.0.

npm

npm install -g @aws-amplify/cli@latest

yarn

yarn global add @aws-amplify/cli@latest

Once that runs it will update your aws-exports.js with the latest backend configuration for the Authenticator. So, zero configuration you have to add, but there’s configuration back there if you need to or want to dig in.

There is then an initial state for the component that sets a user up for sign in, sign up, or resetting their password. You might start with some code to get the component in your page like this.

export default function App() {
  return (
    <Authenticator>
      {({ signOut, user }) => (
        <main>
          <h1>Hello {user.username}</h1>
          <button onClick={signOut}>Sign out</button>
        </main>
      )}
    </Authenticator>
  );
}

Then to set the initial state add the following parameter.

export default function App() {
  return (
    <Authenticator initialState="signUp">
      {({ signOut, user }) => (
        <main>
          <h1>Hello {user.username}</h1>
          <button onClick={signOut}>Sign out</button>
        </main>
      )}
    </Authenticator>
  );
}

Setting many of the other options to your needs includes adding additional parameters to the Authenticator component like;

Social providers

export default function App() {
  return (
    <Authenticator socialProviders={['amazon', 'apple', 'facebook', 'google']}>
      {({ signOut, user }) => (
        <main>
          <h1>Hello {user.username}</h1>
          <button onClick={signOut}>Sign out</button>
        </main>
      )}
    </Authenticator>
  );
}

Sign up attributes

export default function App() {
  return (
    <Authenticator signUpAttributes={[]}>
      {({ signOut, user }) => (
        <main>
          <h1>Hello {user.username}</h1>
          <button onClick={signOut}>Sign out</button>
        </main>
      )}
    </Authenticator>
  );
}

Login mechanisms

export default function App() {
  return (
    <Authenticator loginMechanisms={['username']}>
      {({ signOut, user }) => (
        <main>
          <h1>Hello {user.username}</h1>
          <button onClick={signOut}>Sign out</button>
        </main>
      )}
    </Authenticator>
  );
}

There are lots of other features too, give the docs a quick read for the full details. For more details on the overall authentication worflow check out these docs.

In-App Messaging

In App Messaging

This library is, sadly for my vue.js app, only available for react native. A quick install will get you started.

npm install -E aws-amplify@in-app-messaging aws-amplify-react-native@in-app-messaging amazon-cognito-identity-js @react-native-community/netinfo @react-native-async-storage/async-storage @react-native-picker/picker react-native-get-random-values react-native-url-polyfill

Then install pod dependencies for iOS.

pod install

An example looks like this.

import 'react-native-get-random-values';
import 'react-native-url-polyfill/auto';

import { AppRegistry } from 'react-native';
import App from './App';
import { name as appName } from './app.json';

AppRegistry.registerComponent(appName, () => App);

Then import the awsconfig vis aws.exports.js.

import Amplify from 'aws-amplify';
import awsconfig from './src/aws-exports';

Amplify.configure(awsconfig);

Then integrate the Amplify React Native UI component if your app’s root component.

import {
  InAppMessagingProvider,
  InAppMessageDisplay
} from 'aws-amplify-react-native';

const App = () => (
  <InAppMessagingProvider>
    {/* Your application */}
    <InAppMessageDisplay />
  </InAppMessagingProvider>
);

re: from the docs, here’s an app.jsx example.

import React, { useEffect } from 'react';
import { SafeAreaView, Button } from 'react-native';
import { Analytics, Notifications } from 'aws-amplify';
import {
  InAppMessagingProvider,
  InAppMessageDisplay
} from 'aws-amplify-react-native';

const { InAppMessaging } = Notifications;

// To display your in-app message, make sure this event name matches one you created
// in an In-App Messaging campaign!
const myFirstEvent = { name: 'my_first_event' };

const App = () => {
  useEffect(() => {
    // Messages from your campaigns need to be synced from the backend before they
    // can be displayed. You can trigger this anywhere in your app. Here we are
    // syncing just once when this component (your app) renders for the first time.
    InAppMessaging.syncMessages();
  }, []);

  return (
    <SafeAreaView>
      <InAppMessagingProvider>
        {/* This button has an example of an analytics event triggering the in-app message. */}
        <Button
          onPress={() => {
            Analytics.record(myFirstEvent);
          }}
          title="Record Analytics Event"
        />

        {/* This button has an example of an In-app Messaging event triggering the in-app message.*/}
        <Button
          onPress={() => {
            InAppMessaging.dispatchEvent(myFirstEvent);
          }}
          title="Send In-App Messaging Event"
        />

        <InAppMessageDisplay />
      </InAppMessagingProvider>
    </SafeAreaView>
  );
};

export default App;
In App Messaging

Custom Resources w/ AWS CDK or Cloudformation

René (@renebrandel) wrote a blog post on extending the Amplify backend with custom AWS resources using AWS CDK or CloudFormation. The post is avilable here but I’ll give you a quick summary.

The new CLI comand amplify add custom will get almost any of the AWS services added to an Amplify backend. The core tech here is backed with AWS Cloud Development Kit (CDK) or CloudFormation. For example if you want to pull in AWS SNS as custom resource, this is a very quick and concise way to do just that.

Again, check out René’s post to really get into it and check out some of the possibilities.

Overriding Amplify Backend Resources with CDK

Amplify sets up various capabilities out of the box in many situations such as project-level IAM roles, Cognito Auth, or S3 resources. As with the previous section, this one I’ll keep short as René (@renebrandel) has wrote a great blog post about this capability too titled “Override Amplify-generated backend resources using CDK“. If you’re interesting in nixing (overriding) any of these features and using another choice, this is your go to.

Prototype a Fullstack App without an AWS Account

Not specifically related to the release, this capability that Christian Nwamba AKA Codebeast wrote up in a blog post will show you how to do just that. The docs focused around what he details in the post are avilable here.

GraphQL Transformer v2

This I saved for last, it’s in my wheelhouse after all. Some of the features of the new v2 drop include; deny-by-default auth, lambda authorizer, customizable pipeline resolvers, and OpenSearch aggregations and use-scoped queries. The accomplished blogger, as mentioned in this very blog post, blogging legend René continues with “AWS Amplify announces the new GraphQL Transformer v2. More feature-rich, flexible, and extensible.“.

The first thing René brings up in the post is more explicit data modeling. I’ve stolen two of the screen shots from that post as examples and motivation to click through and check out the post. But I’ll also elaborate.

Adding primary and secondary indexes.

With the new explicit data modeling options, we’ve got @primaryKey and @index added as directoves to configure primary and secondary indexes from schema for your Dynamo Database. The directives in AppSync GraphQL really makes for a powerful schema definition capability to push via code first or to map from database to GraphQL scehma.

Adding relational directives.

The other part that is hugely important is the ability in schema to draw relationships that add referential integrity to your schema and the inherent data. There are now @hasOne, @hasMany, @belongsTo, and @manyToMany directives. I’m really looking forward to some data schema and modeling build outs in the near future. I’ll be sure to put together some tutorials and content detailing some of the design considerations and where and how to get all the schema hacks working best for your particular app data builds.

Thanks & Curated Follows

That’s it for this post. I’m always endeavoring to bring interesting tech and blog about it, but another way to get the quickest updates, links, details, and information about these releases is to follow the following people in the Twittersphere. They’re all in the cohort I run with at AWS with the Amplify team. I owe thanks to each for helping me find the following information and details included in this blog entry.

I Joined AWS, It’s Surreal, and Why

TLDR I joined Amazon Web Services on the 11th of October – i.e. AWS – and it rocks.

When you join Amazon you are signing up to learn a lot of things about the company and the ways in which the company gets things done. Before I get into all that, I’m going to tell you a bit about my career and what led me to Amazon. After all, it is surreal and unexpected for many that know me that I’m here. This relationship has definitely been a 2-way story, and one where it finally fit in a mutually beneficial way.

My First Years in Tech

Years ago, I jumped into the nascent tech industry from the state of Mississippi, where I grew up. Mississippi is quintessentially one of the most regressive, least advanced, disadvantaged, poor, and poorly run states in the entire United States. For most Mississippians life starts rough and continues that way throughout. However there are shining little slivers where tech lives and thrives in the state, and I lucked out in a massive way by cutting my teeth at Stennis Space Center (yes, a part of NASA).

When I got into tech I had no high school diploma and no college. I would eventually attend college but I couldn’t attend yet as I was only 13. I fumbled my way into some coding by taking a programming class. The class used the "Basic" programming language taught by a smart and creative woman that did well to keep the attention of a moderately bored "metal head" 13 year old.

Just a few years later I picked up a C++ book, because one didn’t have the internet to just google their way into learning a new language. That was quickly followed by learning Visual Basic 4, which landed me an opportunity to build a video rental tracking application. I got paid too, a massive $300 bucks! In the next several years I ended up getting into networking, systems administration, more programming and scripting and doing work for doctor’s offices, hospitals, trucking dispatches, junk yards, and a number of other businesses.

I loved the independence this life I’d gotten into gave me. Eventually college came up and I attended some courses, mostly about music and music theory more than programming. But out of a desire to learn faster and cover more topics I left college to advance in the industry.

Fast forward over that following decade and I tore into a plethora of technologies, started working for some giant companies like Bank of America, Citigroup, and Fidelity with hundreds of thousands of people, Government agencies, and some smaller startup like companies.

The famous mythical man-month!

Through all of this experience, and traumatic death march styled work, I came to two decisions that have shaped my career for many years and benefited me in a very significant way.

  1. I was going to cease working for the Government, after years of consulting and related work with the Federal and States Governments I just couldn’t take the lack of control, inability to really effect change, and the general laggard nature of the work. I promised myself I’d stop working in this sector entirely. At this point in my life, I’ve held 100% to that promise, it’s been a rewarding and very effective decision.
  2. I decided I would, likely, stay away from big corporations and also likely stick primarily to small (i.e. SMBs) that allowed me the most impact within an organization. If I were to shift back to a large corporate entity it would have to be with some type of rogue group or segmented team within that organization that fell outside of the general organization itself. So far only one team fit that mold, at Home Depot, but outside of that group I’ve stayed my course and stuck to small business, SMBs, and startups.

Hello Amazon Web Services

"Every day is Day 1." - Corporate Training, but coined per Jeff Bezos

This line in the embarkation of working at AWS stuck out. Which is saying something, because when you join AWS there’s about ~80-120 hours of training videos and culture related content to consume for the coder, techie, project, product, and leader related type of work.

It stuck out because, really, in very real terms this is day 1 of a new career direction for me. I’ve shifted and mutated my 2nd declaration above, in a significant way. I’ve joined AWS to work with the Amplify, AppSync, and surrounding teams to move forward work in GraphQL, data, flows related to, and projects and services around that data space. I’m stoked, but I didn’t join just because of the tech.

Why AWS?

Why join AWS? Even though I’d promised myself not to join anymore big corp companies I got to a point and looked at several of the big companies because I wanted more scope. What I mean by scope is the range of topics, tech, and people that I could work with on a daily basis that were involved in a wide space instead of just a singular narrow space. Startups and small business, by their very nature, work in a singular and narrow space. I still had intent and wanted to work with GraphQL and tech immediately tangential to GraphQL, but I wanted more access, more range, and options to expand the interactions of the tech and expand into access to interactions with people in the industry. So I began a search that eventually led me to join AWS.

That search started with several companies, including AWS. I was looking for several key characteristics that would dictate where I landed.

  1. Involvement in the space, specifically the open source space I wanted to work in. That included several key technologies, depending on what matched best, I’d go that direction: Kubernetes, GraphQL, and general open source development (like Github, etc). This made the options basically Google, Microsoft, AWS, or Facebook!
  2. What company would trigger the least ethical dilemmas for me. Yes, this was indeed part of the criteria I was looking at and discussing. Facebook was already on the shit list considering their political meanderings and inability to fix them. I also just wasn’t sure considering the conflation between actions vs. words. Google was in a moderately ok space, as was AWS, and Microsoft has been doing pretty good on the ethical front as of late. There’s always some questions about things, but I basically wanted to make sure I wasn’t working on things directly helping to cage kids or bomb other countries that are in the stone age back to the stone age!
  3. What company has culture (i.e. specifically good behaviors around meetings, people, etc) that I would appreciate and would work well for me. I’m a rather disciplined, driven, yet ADHD afflicted soul so sometimes, a company’s culture can destroy me or burn me out at 10x the rate of others. I want to join an effort and stick around for some time to really drive home some impact!
  4. How would the team I’m on and teams of people I’d work with, mesh with me. Obviously they’d interview me but I am more than aware, and 100% interview them at the same time. Interviews are absolutely a 2-way relationship and I, as with the last decade plus of my career, have chosen only to work with teams of people that I know are top tier, diverse, open minded, and have a good heart in their efforts.

How It Came Together

I started my search with the premise that I wanted to gain the above four characteristics in which company I joined. I had the privilege and due diligence to choose the company that I could gain all of these, not just a one or a couple of these characteristics. I won’t focus on the companies that didn’t make the cut or why, but I will elaborate on why AWS, and Amazon in general, did indeed make the cut.

  • Leadership principles: One of the things Amazon as a company lives and dies by is the leadership principles. There are a whole host of folks that like to complain, denigrate, nit pick, and come up with reasons why these are bad, but I’ll just cut that off with – when intent is good – they’re all awesome. Full stop. To break down each and personally elaborate:
    • Customer Obsession: yeah, I literally do this work with a priority on who will use it. It’s one of the reasons I focus on minimizing ethical concerns. It then insures that I too can truly be invested in supporting my customers in their efforts. Check.
    • Ownership: I already live by this principle, not just in work life, but personal as well! It’s something I staunchly believe in. Long term over short term, take accountability, act on behalf of not only yourself but others. Step up, there’s a lot that needs to be done in this world! Check.
    • Invent and Simplify: The mantra I’ve basically lived my whole programming career by. If I can’t build things to work myself out of work, and I can’t find a better way to do something after doing it for a while, I’ve started to fail at what I’m doing. I work in this field to make things easier, better, and more resilient for the users’ of the things I build and help others build. Check.
    • Are Right, A Lot: Nuff’ said.
    • Learn and Be Curious: Just scroll through and read the posts on this blog, follow me @Adron or streaming @ThrashingCode. You know I’m all about this. Check.
    • Hire and Develop the Best: Well, I haven’t hired anybody yet at AWS, but I’ve hired a lot of people in my career so far. I don’t hire you if you won’t or can’t be the best, thus, if I ever do hire you, you can rest well knowing I vouched for you and know you can kick ass and take names! 🤘🏻
    • Insist on the Highest Standards: We can talk about the pedantic nature of this leadership principle in the future and joke about tablets later. Check.
    • Think Big: Always. Check.
    • Bias for Action: People’s lives continue today because of my bias for action. If you know me, you”ll understand this comment. If not, feel free to ask, I’ve just summarized it with this statement for this post. Check.
    • Frugality: At work, yup. At home, no comment. Albeit I would own a plane or launch rockets in a frugal way too if I had the financial resources. Check.
    • Earn Trust: I’m always working to earn trust among those I trust and respect. I hope we all are, it’s a remarkably good way to live. Check.
    • Dive Deep: I’m on it. Check.
    • Have Backbone; Disagree and Commit. Thanks brutally, caustic, and toxic southern upbringing, and thanks west coast for helping me tone that down to an effective level of having backbone, disagreeing and committing in life. Check.
    • Deliver Results: I’ll admit, this one I’m a little afraid to ask why it even needs to be listed. Check.
    • Strive to be Earth’s Best Employer and Success and Scale Bring Broad Responsibility: I’ll do my part but I’ll leave these as is for today. There’s work to be done! Check.
  • The team and members on the periphery of that team checked all the boxes (good job!), were friendly, easy to converse with, and are top tier people in this industry! During my initial loop I got to speak with, meet, and I highly recommend following each of these people if you don’t already, and more benefit if you are interested in the work we’re doing:
    • Bill Fine -> @billfine
    • Brice Pellé -> @bricepelle
    • Ed Lima -> @ednergizer
    • Robert Zhu -> @rbzhu
    • Ali Spittell -> @ASpittel
    • Mohit Srivastava -> @mohit
    • I also met and spoke with Aleksej Trefilov and Ben Snellings, but we can’t discuss all the cool secret thigns they’re working on, so I’ll just leave it at – awesome to meet them, if you get a chance to work with them sign up!
    • Big shout out too to Adam Desai and Mashayla too! Adam is the recruiter that I worked with and got all of the loops lined up, and Mashayla joined in to make sure everything got coordinated and scheduled! Great experience and good workflow y’all have!
  • Around the culture aspect, as I spoke to the team and others in the immediate teams I dove into a number of culture questions. One of the things that summarizes the drive and energy at AWS is the principled and organized nature of meetings starting with a document read – everybody reads the document – then the meeting resumes around discussion of the document, the details, data, and the participants take actions based on that. It’s a very effective way to run meetings. Beyond that however, the general readiness of the team, the approach and interactions of everybody involved, was excellent. The conversations during the interview, the tests and challenges, all were great fun and I got a lot of information (and I got the job, so I suspect I provide good information!) and enjoyed the interactions. I got a solid feeling we’d mesh well. Another criteria, check!

Now all of this didn’t go off without a hitch, because of certain things I got to do a second short loop and my role switched from Developer Advocate DA to Product Manager Technical. This worked out very well however, as now I’m positioned to have impact from work as a developer advocate and product management efforts.

There were other competing offers from Google, Microsoft, and other companies I interviewed with at the same time. In the end though the responsiveness, effective flexibility from the team and Adam led to AWS coming out the winner. With everything wrapped up and questions answered, all criteria met, I gave AWS and the team a solid YES!

With that I’ve joined AWS! Ready for new challenges and bringing a simpler, faster, more usable Amplify, AppSync, and Cloud environs to every coder out there! Let’s do this! 🤘🏻

The Conversations and Samples of Multi-Cloud

Over the last few weeks the I’ve been putting together multi-cloud conversations and material related to multi-cloud implementation, conversations, and operational situations that exist today. I took a quick look at some of my repos on Github and realized I’d put together a multi-cloud Node.js sample app some time ago and should update it. I’ll get to that, hopefully, but I also stumbled into some tweets and other material I wanted to collect a few of them together.

Some Demo Code for Multi-Cloud

Conversations on Multi-cloud

  • Mitchell Hashimoto of HashiCorp posted a well written comment/article on what he’s been seeing (for some time) on Reddit.
  • A well worded tweet… lot’s of talk per Google’s somewhat underlying push for GKE on prem. Which means more clouds, more zones, and more multi-cloud options.

  • Distributed Data Show Conversations

 

 

 

Leave a comment, tweet at me (@adron), let me know your thoughts or what you’re working on re: multi-cloud. I’m curious to learn about and know more war stories.

Top 4: “Nobody Reads Blogs… Except Everybody Read Blogs”

I know I know, the marketers say it’s all about the single articles now. Nobody reads blogs. Nobody subscribes to blogs. Ya know, except of course for that small percentage of people that do.

…marketing, it’ll make you insane if you’re not careful.

But seriously, here’s a few blogs that are actually worth reading. They’re worth subscribing to and surprisingly, they’re blogs that businesses organize and write. Yes, I have and might be writing for some of them in the future. But I’m honestly basing this list on a few specific criteria:

  • The blog has to include some technical content that is important to getting kick started with their product and getting kick started with other tooling around their space.
  • The blog has to include articles that have industry information that is relevant to conferences, meetups, and other community related activities.

Here’s my list of reads lately:

Continue reading “Top 4: “Nobody Reads Blogs… Except Everybody Read Blogs””

Mapping Domain Names with name.com, Elastic Beanstalk, Elastic Load Balancer and AWS Route 53

I finally wrapped up my name server and DNS mapping needs with Name.com, Route 53 and Elastic Beanstalk. Since this was a little confusing I thought a short write up was in order. Thanks to Evan @evandbrown for helping out!

The first thing needed is a delegation set of name servers for your DNS and name server provider. These can be found by creating a hosted zone. The way to do this is open up the AWS Management Console and navigate into the Route 53 management area. The Route 53 icon is under the Compute & Networking section on the management console.

Beanstalk, Route 53 - Click for full size image
Beanstalk, Route 53 – Click for full size image

Upon navigating to the Route 53 console area click on the Create Hosted Zones button.

Create Hosted Zone
Create Hosted Zone – Click for full size image

When the zone is created then the delegation set can be found under the Hosted Zone Details. This delegation set now needs setup as the name servers for whoever, in this case name.com, is the domain provider.

Delegation Set - Click for full size image.
Delegation Set – Click for full size image.

Open up the management console for the name server administration.

Upon adding them the list should look something like this.

Name servers list built from the delegation set of the hosted zone. Click for full size image.
Name servers list built from the delegation set of the hosted zone. Click for full size image.

Once the name servers are setup, those will need time to propagate. Likely this could take a good solid chunk of time, somewhere in the hours range likely, and don’t be surprised if it takes a little bit more than a day.

While the propagation starts navigate back to the AWS Management Console and open up the EC2 section of the console. On the right hand side of the Resources list there is a Load Balancers section. Click it.

Load Balancers - Click for full size image.
Load Balancers – Click for full size image.

In this section there is a listing of all load balancers that have been created manually or by Elastic Beanstalk.

Load Balancers - Click for full size image.
Load Balancers – Click for full size image.

Make note of the Load Balancer Name for selection in Route 53. This is what Route 53 needs in order to point an alias at for incoming traffic to that particular Elastic Beanstalk application. In this particular image above there are 4 load balancers listed, the easiest way to prevent confusion is to take note of the load balancer name at the time of creation, but this is the easiest way to find them otherwise.

Record Set - Click for full size image
Record Set – Click for full size image

Now when going back to the hosted zone to set it up with the appropriate information, create a new record with the appropriate name, in this case I was setting up the admin.deconstructed.io (no it isn’t live yet, I just set it up to test it out) to point to an alias target. Just leave the Type set to A – IPv4 address and click the radio control so that Alias is set to Yes. In the alias target select the appropriate load balancer for the Elastic Beanstalk (or whatever it points to) application.

That’s it, give it a few hours (or a day) and eventually the domain or subdomain will be pointed appropriately at the Elastic Beanstalk load balanced application.