Forem: Michael Timbs

Creating a serverless-deploy user with AWS IAM

Michael Timbs — Sun, 08 Mar 2020 14:38:19 +0000

If you are building a project with AWS serverless using SAM or serverless framework , you’ll need to be regularly deploying your code from your local machine and CI/CD pipelines. Both of these frameworks use AWS CloudFormation under the hood to provision and deploy resource stacks. In order for these frameworks to provision your infrastructure for you, you will need to give them permission to do so.

NOTE: This article assumes you already have the AWS CLI installed and configured. You will need to set that up first. Instructions can be found here.

Firstly log into your AWS console and navigate to Identity and Access Management (IAM). Go to Users *and the create new user. Name it something that is easy to identify like *serverless-deploy. Ensure programmatic access is enabled.

AWS Console — Create User

Click through next, giving it no permissions, if required add some tags, otherwise click next. Download the user credentials (don’t lose these, you can’t recover them again) and then let’s add them to our local CLI.

AWS credentials are typically stored in ~/.aws on your local machine if you have configured the AWS CLI.

We’re going to add the following snippets to the config and credentials files in the .aws directory. See below.

~/.aws/config
[profile serverless-deploy]
region=<your-region>
output=json

~/.aws/credentials

[serverless-deploy]
aws_access_key_id = <access-key-here>
aws_secret_access_key = <secret-key-here>

*Note: *You can name your profile whatever you want and substitute “serverless-deploy” with whatever you want to call it.

We should now be able to deploy a serverless project locally from our machine. Below is an example of what you would do if you were using serverless framework.

sls deploy --stage dev --aws-profile serverless-deploy

At this point you should get an error. Most likely

- not authorized to perform: cloudformation:DescribeStacks

We now need to go and give this IAM user permission to create resources for us and spin up infrastructure based on our CloudFormation templates. Back in our AWS console we will need to create an IAM group *serverless-deploy *(or whatever you want to call it). We won’t any policies to it here but will create those separately.

We will now create a new IAM policy to attach to this group.

In this policy we will add a policy for the CloudFormation *service and then allow the Actions *List:DescribeStacks. *Indicate that this permission applies to all resources and then click *Review Policy. You’ll be prompted to give this policy a name, again something like serverless-deploy is fine. Give it a description if you like and then click Create Policy.

AWS IAM Console adding CloudFormation:DescribeStack permission to our user

*Note: **You can either create a universal *serverless-deploy user for all services/projects, or create a specific one for each project. If you want to create a specific one for each project you can limit the resources you give this user permission to.

Now that we have created the policy, we need to attach it to the group we created before. Go back to groups, find the group we created before and click on Attach Policy.

AWS Console — Attach Policy

Search for the newly created policy and attach it to the group.

AWS Console — Attach Policy

Our serverless-deploy group now has a policy attached. We should now put our IAM user into this group so that it inherits it’s policies. We need to go back to our Users tab and then click on our user. Navigate to the Groups tab on the user info screen and attach a group.

AWS Console — IAM Users

Now we can add the serverless-deploy group to the user.

AWS Console — IAM User Add user to groups

With these changes we can try deploying our app again and see what happens.

sls deploy --stage dev --aws-profile serverless-deploy

We should get another error, although this time the error will be different.

user/serverless-deploy is not authorized to perform: 

cloudformation:CreateStack on resource

This is progress, which indicates that the work we just did at least changed something and appears to have worked. In the AWS console, go back to *Policies *and search for the serverless-deploy policy we created earlier.

AWS Console - Policy Summary

Click edit policy and add the CreateStack permission in the CloudFormation service. Review and save.

AWS Console — IAM policies

Rinse and repeat this process of deploying and then adding each policy incrementally. This is the best way to ensure you have the minimum possible permissions and avoid security risks of giving your IAM users too much access.

**Hint: **Sometimes the console output isn’t great so you can look at the CloudFront events log in the AWS console to get the errors.

AWS Console — CloudFormation events

*Note: *If you keep going with this process you may have to manually delete some resources and the CloudFormation stack as you’ll hit an error, the stack will try to rollback but then not have permission to roll back.

Once you successfully get a deploy working I recommend creating an IAM.json in your project and copying across the final policy to your project and committing it to the repo. This will enable you to quickly duplicate this stack between staging/production accounts.

HINT: It is often best to go through this iterative process in a development account. Then once you have the final permissions, copy them across into your production account so that your deploys don’t fail and have unintended consequences. You can read about multiple accounts here

For the base template of a new serverless project (like the one here) the basic permissions should be as follows. Feel free to verify these permissions and copy them straight into your IAM policy if you are happy with them.

Get Started With AWS, Serverless, and TypeScript

Michael Timbs — Sun, 08 Mar 2020 14:07:03 +0000

About five months ago, I got thrown head first into the world of serverless when I joined the team at fleet.space to build cloud infrastructure to support their nano-satellite constellation and industrial IoT network.

I really struggled to find a comprehensive guide on how to build new services with TypeScript, so here I am writing the one I wish I had. We won’t go through any example code — we’ll just focus on building up a robust base template you can reuse for all your services.

The first thing we’re going to do is install the Serverless Framework. I find it has better support than the official AWS SAM templates.

First, lets install Serverless as a global dependency on our system via npm i -g serverless. Next, we’ll create a project, mkdir typescript-serverless. Inside that directory, let’s scaffold out a new Serverless template with the following command:

sls create --template aws-nodejs-typescript

This will generate a bare-bones template with TypeScript, but it’s missing a lot of powerful configuration I use over and over again. So let’s set some of these things up. If you don’t use VS Code, go ahead and delete the pesky VS Code directory this template initialises, and then run npm i to install the base dependencies of the Serverless Framework.

Serverless Plugins

The Serverless Framework has one advantage over SAM in that there are many community plugins built around it to help you do things (and you can build your own, if needed). It’s very extensible. Plugins I use in almost every service are:

serverless-iam-roles-per-function

This plugin allows you to define IAM permissions at a function level instead of the default project level. If only one function needs to touch DynamoDB then we don't need to give them all access.

serverless-create-global-dynamodb-table

Multi-region deploys are essentially free in the serverless world (compared to containers/ec2 anyway). The only complexity is keeping DynamoDB in sync. This can be done with a global table.

serverless-offline

This one I don't always use these days but it's only a dev dependency and handy to have. It will let you invoke your lambda API locally.

serverless-prune-plugin

This is a sneaky risk with serverless, especially if you deploy frequently. Lambda will version each function you deploy and there is a hard storage limit to how many you can store. This plugin will prune old versions that aren't needed and prevent that subtle error hitting your production environment.

npm i -D serverless-iam-roles-per-function serverless-create-global-dynamodb-table serverless-offline serverless-prune-plugin

We’ll also add aws-sdk and aws-lambda

npm i aws-sdk aws-lambda.

Lambda Powertools

One thing I really struggled with when I stepped into the world of serverless was observability and traceability. Debugging across service boundaries and even infrastructure within boundaries (Lambda > SQS > Lambda > Kinesis > Lambda > DynamoDB, etc.) was a pain. Thankfully I came across a great set of powertools for Lambda that are a must-have in any service.

@dazn/lambda-powertools-cloudwatchevents-client
@dazn/lambda-powertools-correlation-ids
@dazn/lambda-powertools-logger
@dazn/lambda-powertools-pattern-basic
@dazn/lambda-powertools-lambda-client
@dazn/lambda-powertools-sns-client
@dazn/lambda-powertools-sqs-client
@dazn/lambda-powertools-dynamodb-client
@dazn/lambda-powertools-kinesis-client

I just import all of these and let webpack tree shaking worry about getting rid of what I’m not using.

npm i @dazn/lambda-powertools-cloudwatchevents-client @dazn/lambda-powertools-correlation-ids @dazn/lambda-powertools-logger @dazn/lambda-powertools-pattern-basic @dazn/lambda-powertools-lambda-client @dazn/lambda-powertools-sns-client @dazn/lambda-powertools-sqs-client @dazn/lambda-powertools-dynamodb-client @dazn/lambda-powertools-kinesis-client

Linting

The next important thing I can’t live without in a codebase is linting. ESLint is one of the biggest crutches I use everyday. Let’s configure it to work with TypeScript and the Serverless Framework. We’ll need the following dev dependencies.

npm i -D eslint eslint-config-airbnb-base typescript-eslint eslint-plugin-import eslint-import-resolver-alias eslint-plugin-module-resolver @typescript-eslint/eslint-plugin @typescript-eslint/parser

Now, we need to create an .eslintrc.json config file to define our rules. I like the following rules. This gist also includes some alias mapping for some module aliases we’ll set up at the end and some Jest config we’ll set up in a second.

I’ll also tweak my tsconfig file to add inlineSource, esModuleInterop, sourceRoot, and baseUrl. The following gist also pre-populates some module aliasing information we’ll set up later. You can comment out anything in paths for now, if you want.

Testing

I’ll write tests for every service so it makes sense to configure a test runner in our base template. I personally like Jest, so we’ll set that up.

Once again, we’ll need to fill the the black hole of our node_modules with some npm dev dependencies.

jest
babel-jest
@babel /core
@babel /preset-env
@babel /preset-typescript

npm i -D jest babel-jest @babel/core @babel/preset-env @babel/preset-typescript

Make sure that Jest is configured as a plugin in your .eslintrc.json and that you set jest/globals under env (if you copied the gist above, you’ll have this in there already).

We need to create a Babel .config for Jest to work.

At this point, we should check to see if Jest is working and if it’s configured correctly. Lets create a tests directory and add an example test. Create a test file, and let’s add a dummy test, tests/example.test.ts.

describe('who tests the tests?', () => {
  it('can run a test', () => {
    expect.hasAssertions();
    expect(1).toBe(1);
  });
});

If you’re using WebStorm, you can hit Ctrl+Shift+R to run this test straight from your IDE. Otherwise, let’s go update our package.json to add a test script (and a lint and TS compile check while we’re there).

In your package.json file, update the scripts section to include the following:

"scripts": {
  "test": "NODE_ENV=test ./node_modules/.bin/jest --ci --verbose",
  "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
  "buildtest": "tsc --noEmit"
 },

I generally run all of these in CI/CD pipelines to prevent bad code from hitting production. Now, you can run npm run test from your console to run the test suite. Hopefully, your test suite runs and passes. Ideally, your IDE won’t be throwing linting errors at you in your example.test.ts file either.

While we’re here, run npm run lint, and let’s see if there are any linting errors with the default template. You’ll likely get some errors with webpack.config and the handler.ts file that was autoscaffolded. Let’s clear these up.

At the top of your webpack.config file, add */* eslint-disable @typescript-eslint/no-var-requires */* and uncomment out the Fork TS Checker Webpack Plugin defaults that came with the template. That should solve that file.

For the handler.ts file, just go remove the unused context-function signature from the hello function.

Code goes in /src

One convention I like is putting all our domain logic inside a /src directory and leaving the root for the config (and /tests). Create a /src directory, and move the handler.ts file inside of the /src directory.

If you decide to adopt this convention, you’ll need to go to serverless.yml and update the path for the handler to src/handler.hello.

Let’s configure our Serverless plugin while we’re in the serverless.yml file.

    service:
      name: typescript-serverless

    ...

    plugins:
      - serverless-offline
      - serverless-webpack
      - serverless-iam-roles-per-function
      - serverless-create-global-dynamodb-table
      - serverless-prune-plugin

    ...

At this point, you should be able to run sls offline in your terminal and have a clean compile and build launching a Serverless offline endpoint.

    ➜  typescript-serverless git:(master) ✗ sls offline
    Serverless: Bundling with Webpack...
    Time: 398ms
    Built at: 27/02/2020 11:24:42 pm
      Asset      Size       Chunks             Chunk Names
      src/handler.js  6.33 KiB  src/handler  [emitted]  src/handler
      Entrypoint src/handler = src/handler.js
      [./src/handler.ts] 316 bytes {src/handler} [built]
      [source-map-support/register] external "source-map-support/register" 42 bytes {src/handler} [built]
    Serverless: Watching for changes...
    Serverless: Starting Offline: dev/us-east-1.

    Serverless: Routes for hello:
    Serverless: GET /hello
    Serverless: POST /{apiVersion}/functions/typescript-serverless-dev-hello/invocations

    Serverless: Offline [HTTP] listening on http://localhost:3000
    Serverless: Enter "rp" to replay the last request

Hopefully, you see this. You should be able to visit localhost:3000 and see a list of available API endpoints. If you go to /hello, things should see a dump of the APIGatewayProxyEvent we return in src/handler.ts.

    import { APIGatewayProxyHandler } from 'aws-lambda';
    import 'source-map-support/register';

    export const hello: APIGatewayProxyHandler = async (event) => ({
      statusCode: 200,
      body: JSON.stringify({
        message: 'Go Serverless Webpack (Typescript) v1.0! Your function executed successfully!',
        input: event,
      }, null, 2),
    });

Serverless Config

Now that we have a working API Gateway endpoint, let’s configure a few more options in the Serverless Framework.

Set up X-Ray tracing for functions
Set some default .env variables
Lock the version of Serverless
Set stage and region configs with defaults
Set up global DynamoDB plugin
Set up automatic pruning for lambda versions (we'll retain the last 3 versions only)


    service:
      name: typescript-serverless

    custom:
      webpack:
        webpackConfig: ./webpack.config.js
        includeModules: true
      serverless-iam-roles-per-function:
        defaultInherit: true *# Each function will inherit the service level roles too.
      globalTables:
        regions: # list of regions in which you want to set up global tables
          - us-east-2 # Ohio (default region to date for stack)
          - ap-southeast-2 # Sydney (lower latency for Australia)
        createStack: false
      prune: # automatically prune old lambda versions
        automatic: true
        number: 3

    plugins:
      - serverless-offline
      - serverless-webpack
      - serverless-iam-roles-per-function
      - serverless-create-global-dynamodb-table
      - serverless-prune-plugin

    provider:
      name: aws
      runtime: nodejs12.x
      frameworkVersion: ‘1.64.1’
      stage: ${opt:stage, 'local'}
      region: ${opt:region, 'us-east-2'}
      apiGateway:
        minimumCompressionSize: 1024 *# Enable gzip compression for responses > 1 KB
      environment:
        DEBUG: '*'
        NODE_ENV: ${self:provider.stage}
        AWS_NODEJS_CONNECTION_REUSE_ENABLED: 1
      tracing:
        lambda: true
      iamRoleStatements:
        - Effect: Allow
          Action:
            - xray:PutTraceSegments
            - xray:PutTelemetryRecords
          Resource: "*"

    functions:
      hello:
        handler: src/handler.hello
        events:
          - http:
              method: get
              path: hello

Under provider, we set a default stage and region and some global .env variables for the service. We also set up X-Ray tracing so we can easily debug our service once it’s deployed.

We also locked our version of the Serverless Framework. I’ve not done this before and had deploy pipelines break when Serverless bumps up a version and breaks one of our plugins. At the time of writing, this the version is 1.64.1.

Finally, we set the stage and region configs with some defaults of local and us-east-2. These are set as CLI arguments (optional) during deploy.

Lastly, we configured some global IAM role statements for the service. (These are the only global roles we’ll set. Everything else we’ll set at a per-function level).

Note: You’ll want to comment out the global tables for your initial multi-region deploy. This plugin may not work as you expect. The reason this may fail a deploy is outlined here.

Module Aliasing

The last thing to configure is module aliasing. It really blows my mind people are building Node apps in 2020 without using module aliasing. Relative import paths are too fragile for me, so let’s set up some aliases.

We are going to set three defaults (src, test, and queries) just so someone can come in and know how to set them up in the future. We’ll also use an import from queries in our example handler to make sure TypeScript compiles and resolves correctly.

Now this is a bit messy, but let’s go set this up. It’s worth the effort.

First, let webpack know about module aliases and updating the resolve object.

    resolve: {
      extensions: ['.mjs', '.json', '.ts'],
      symlinks: false,
      cacheWithContext: false,
      alias: {
        '@src': path.resolve(__dirname, './src'),
        '@queries': path.resolve(__dirname, './queries'),
        '@tests': path.resolve(__dirname, './tests'),
      },
    },

Next, we’ll let our .tsconfig know about the module aliasing by updating the compilerOptions path (we can also refer to the tsconfig gist earlier).

    "paths": {
      "@src/*": ["src/*"],
      "@queries/*": ["queries/*"],
      "@tests/*": ["tests/*"]
    }

Lastly, we’ll let ESLint know about it so we don’t get pesky linting errors when we alias. (Again, this was done in the earlier gist if you just copied that.)

    "settings": {
      "import/resolver": {
        "alias": {
          "map": [
            ["@src", "./src"],
            ["@tests", "./tests"],
            ["@queries", "./queries"]
          ],
          "extensions": [
            ".ts",
            ".js"
          ]
        }
      }
    }

OK, time to make sure this is configured correctly.

Lets go create a /queries directory and add queries/exampleQuery.ts to validate our aliasing. We’ll make this module as simple as can be to test the compilation still works.

export const echo = (sound: string): string => sound;

We’ll just take a parameter and return it straight back. We’ll get a compile time error if this doesn’t work.

Now in src/handler.ts, lets import this module with the alias we set up and try to use this in our response. Let’s update the message in our response.

import { APIGatewayProxyHandler } from ‘aws-lambda';
import { echo } from ‘@queries/exampleQuery';
import 'source-map-support/register’;

export const hello: APIGatewayProxyHandler = async (event) => ({
  statusCode: 200,
  body: JSON.stringify({
    message: echo(‘Module aliasing is really the best’),
    input: event,
  }, null, 2),

Using the aliasing makes refactoring so much simpler. Your IDE should also be smart enough to autoimport with aliases (WebStorm is anyway).

And that’s about all there is to it. You should be good to start writing code and build out your services with all the goodness of TypeScript, ESLint, and Jest. I’ll cover how to use some of the powertools and how to set up SQS, SNS, Kinesis, and DynamoDB in a future post.

You can find this entire starter template on my GitHub.

For information on how to deploy this project to your AWS account by configuring IAM roles, read here.

When to Use Vue Over React

Michael Timbs — Sun, 08 Mar 2020 13:26:57 +0000

A highly opinionated article based on my experience as a front-end web developer over the last four years.

I use React professionally at my current job, but I choose Vue for all personal projects. It’s my preferred framework of choice. I’ve used Vue in previous (publicly traded) companies, and it scaled incredibly well.

Any seasoned developer will tell you software is all about trade-offs and throwing around objective statements like “Framework x is better than Framework y” are generally meaningless. By what metrics? In whose opinion? For this reason, I’ll compare Vue and React across three main concerns that are often competing trade-offs.

Performance
Scalability
Job Market

Performance

Performance is usually where people want to start when discussing frameworks or languages. Everyone who writes software is building the next FAANG company, and every nanosecond of performance must be extracted from our code.

I’m going to compare both frameworks on two components of performance, namely silicon time and carbon time. Silicon time refers to the raw execution performance — how fast it can run in the browser. Carbon time refers to how fast developers can build products in the code.

Silicon-time comparison

React leverages JSX, which gives developers a lot of power to build arbitrarily complex logic. We can harness the Turing-complete power of JavaScript and treat our view as data. Something like Svelte leverages templates for markup that provide a rigid structure to the view layer.

React and Vue both use a virtual DOM (VDOM), which, while practically fast enough, is inherently expensive and almost purely overhead. Svelte compiles template code to raw JS and manipulates the DOM directly, which means it doesn’t have the performance overheads of maintaining a VDOM.

What I love about Vue is it hedges its bets a little bit. The most common way to use Vue is to use templates in single-file components. This has allowed the Vue team to do some very clever things in the upcoming Vue 3 release with ahead-of-time (AOT) optimisations.

The structured nature of a templates means a compiler can know things about your code and perform optimisations. The main optimisation Vue introduces is dropping all static data from the VDOM diff. VDOM performance is directly affected by the number of nodes it has to track. By filtering out static data from this VDOM-diffing process, we can reduce the number of nodes being tracked. This makes the code run much faster as it doesn’t have to compare a recursive tree of arbitrary nodes at each render cycle.

While Vue appears to use templates in most cases, the compiler actually turns these templates into render functions for you under the hood. This means any time the templating of Vue is getting in your way, you can directly drop down and write render functions exactly like you would in React. This means you get all the flexibility of render functions and JSX that you get in React with some of the performance benefits you get from a templated framework like Svelte. Obviously, if you write a Vue application with 100% render functions, you lose all of the template optimisations.

Code benchmarks are a bit of a waste of time, in my opinion, but a few show Vue 2 around 2.5x faster than default React, and Vue 3 is benchmarking 3-5x faster than Vue 2. In practice, the JS framework you use is going to be such a small component of your application that these benchmarks are nearly meaningless. However, if you’re building templates that’ll leverage Vue 3’s AoT optimisations from templates, there’s just no way the same app will be faster written in React.

Winner: Vue

Carbon-time performance

A senior developer will cost you around $150/hr depending on where you are in the world. Even junior to midlevel developers are earning a good enough salary that you want to be factoring in development time and costs into your technical stack. It’s the reason why languages such as PHP, Python, Node, Ruby, etc. are so popular and we don’t just write everything in C.

For front-end applications, we’re constrained by the browser, device resources, and network latency, so silicon performance is still a contributing factor — but carbon performance should also be at the forefront of any CTO’s mind.

In my opinion, the single greatest contributing factor in the success of Vue has been its approachable documentation, resources, and ease of learning. I learned React and Vue at the same time, and Vue was noticeably easier to get started with. If you know HTML, CSS, and the bare basics of JS, you can build an application with Vue. I’ve spent half a day with a design team and had them shipping changes to production front ends in Vue. This frees up a lot of time for the dev team and allows designers to implement A/B tests and design updates without getting blocked by the software backlog.

One of the things I love about Vue is the layered design of its opt-in tooling. You can start by pulling in Vue via a CDN. That means you can play with it without needing to go through complex build steps (webpack/Babel config, npm, etc). You can then progress to the Vue CLI and build basic apps. If you then need a state management solution, there’s an officially supported and documented solution in Vuex. Similarly, Vue Router is an officially endorsed and supported router solution for Vue.

On the other hand, React introduces the paradox of choice, which can make things hard for newcomers.

React is a small-scope, single-purpose library that introduces a component model that receives props and returns a VDOM tree. This provides a lot of flexibility and the React community has built many complex systems on top of this simple library.

There’s a large ecosystem with many, many options available to solve tasks. These are maintained independently by users. This model provides a lot of opportunities for people to build things on top of React and build popular libraries and tools.

It also makes things very difficult to find and learn. You’re stuck choosing the best option for state management or routing or configuring a new application. In my experience, this also makes hiring React developers harder. When there’s multiple ways to do things, onboarding new members to a React project has more friction than onboarding to a Vue project.

Winner: Vue

Scalability

Most of my thoughts on the scalability of these frameworks was touched on in the performance section. Scalability is often intrinsically linked with performance, so it’s not surprising.

I generally think of scalability in terms of:

Scaling the number of views/components/workflows in an application

In terms of scaling out the number of components, I’m a really big fan of the single-file component (SFC). The logical grouping of a component makes a lot of sense to me. Many people disagree with this, and it’s a matter of opinion rather than an objective statement.

The reason I love SFCs is because they provides a great way to enforce the separation of concerns (SoC).* *Some people argue that mixing HTML, CSS, and JavaScript is doing the opposite of separating concerns. I’ve changed the way I think about this principle on the front end, largely with my obsessive adoption of Tailwind CSS for styling my components.

Adam Wathan wrote a great articleon the notion of SoC and how it applies to HTML and CSS. I think about my front-end components in a similar way. In my mind, a component is how it looks (HTML/CSS) and how it works. Separating the markup from the JS feels arbitrary to me. If you consider your views as data, then (to me) it makes sense to group them with your data.

Don’t even get me started on JSX and CSS-in-JS. HTML and CSS are not dead. They’re incredibly powerful building blocks of the web. Use them!

The benefits of officially supported solutions to common problems also comes in handy at scale. If you’re having trouble scaling a Vue application, then chances are any other Vue application at scale has used the same architecture, and you’ll be able to find advice and help. You don’t need to worry about people saying, “Just use hooks/MobX/Redux/Redux-Saga.”

Scaling the number of developers on a team

I’ve already mentioned I’ve previously seen a design team empowered to push changes to production with a few hours of help. That’s an insane productivity boost to any consumer-facing application.

The general consensus that Vue is easier to learn also means you can train junior developers to a point of net benefit to the team much much faster. You can also onboard a React developer (assuming they know HTML and CSS) with little effort.

Again, having consistent solutions to common problems makes code review and reasoning about a large codebase that much easier for everyone on the team.

The key thing with both of these is maintaining development velocity while keeping a performant application that meets the needs of your users. Vue strikes the perfect balance here as far as I’m concerned.

Winner: Vue

The Job Market

OK, so I’ve convinced you Vue is better than React in every conceivable way. But this is meaningless if you can’t get paid (or find devs to hire).

React has a much higher share of the job market (at least in Australia and the United States). If you look on most job boards, the number of React jobs advertised relative to Vue is significant (nearly 8x as many React jobs at the time of writing this based on 10 seconds of job-board searches).

While React appears to win on this metric, I refuse to let React get points on the board, so I’ll make the following (water-tight, unassailable) argument.

There are opportunities for both React and Vue in the job market. Companies using Vue or React both find it difficult to hire, and, in my experience, there’s a skills shortage for both. As someone looking for work, you can achieve mastery (or perceived mastery) of Vue much faster than you can with React. This means you should get an accelerated path to higher salaries. You’ll also have less competition when interviewing as React is still the most popular choice for many developers who are currently victims of the sunk-cost fallacy.

As a company or hiring manager worried about competing for talent in the current market, Vue offers an opportunity to build more product per resource (carbon time benefits of Vue) and to grow your own talent (faster learning curve). Choosing Vue for greenfield projects or a new startup could just be the best decision you ever made when it comes to hiring.

As more companies realise the benefits of Vue, I believe it’ll continue to swallow market share — and may even overtake React as the framework of choice in the future.

Winner: Tie

Conclusion and Closing Remarks

This was a semi-tongue-in-cheek article about Vue and why I think it’s superior to React. I think React is a perfectly reasonable tool for building front ends, and I’m not claiming it’s bad. I just believe Vue has achieved a better balance in framework design.

I would choose React over Vue in the following scenarios:

You want to work somewhere that uses React — e.g., Facebook
You have a team of experienced React developers
It’s easier to hire for React in your area

I honestly don’t think there’s a single technical reason I’d choose React over Vue for the kind of applications I build or work on. This doesn’t mean one doesn’t exist, but I’ve just not come across one yet.

Svelte and Elm are both incredibly interesting options I’m following closely but am uncertain about their viability for large-scale enterprise applications at this point in time.

If you want to learn Vue, I highly recommend this free course by the amazing Jeffrey Way.

Switching Between Multiple AWS Accounts

Michael Timbs — Wed, 04 Mar 2020 22:12:03 +0000

Whether you use AWS across your organisation or for personal projects, it is useful to set up multiple accounts on AWS to seperate your staging/test and production environments. It is especially useful if you are building serverless applications as many of the tools you will use (e.g. Lambda) have soft limits on concurrent usage at the account level.

Apart from getting around usage limits, separating your development and production accounts allows you to experiment in a real cloud environment without negatively impacting your production environment.

The naive way of doing this involves constantly logging out and back in each time you want to change accounts, or to set up multiple chrome profiles that save your credentials for each account. Instead you can leverage assumed roles via IAM permissions and Organisation Units.

AWS Organisations

AWS console — Navigate to My Organisation

Under your root AWS account create an organisational unit. Below I’ve created Production, Staging and Playground organisation accounts. Production and Staging are generally fine for most companies. I use playground as a place to try new AWS products in an environment I know I can safely nuke anything at any time.

Note: All the accounts we are about to create all get billed in your root account.

AWS Console — Organisation Unit View

Once we have created these organisational units, we are going to need to add user accounts to them. Under Accounts we are going to create some new accounts

AWS Console — Create Account View

The AWS account name I generally name after the organisational unit to keep things clear. The email I will usually do something like michael+@domain.com. Leave the IAM role name as the default *OrganizationAccountAccessRole *(this is important).

Note: AWS requires unique emails, so adding the “+pod” etc will satisfy that requirement while still delivering emails to your primary domain.

Once you create these users, you’ll need to wait 1–5 minutes for an invitation email from AWS. You’ll then need to use the forgot password functionality to set a password for these accounts. I suggest using a password manager and making these strong.

Create an IAM User

Once we have the root accounts for production and staging, we need to create a user that can easily hop between these accounts. Unfortunately (and for reasons that aren’t clear to me) root accounts can not hop between other root accounts. We’ll need to create a dedicated IAM user and then give them access to all the accounts we created (root, production, staging etc).

AWS Console — Create IAM user

We give this user a username and give them access to the AWS management console. It’s important that we don’t give programmatic access here — if we need programmatic access to these accounts (for deployments via CLI etc, we will use the root credentials or create new ones). This user is merely for hopping between the AWS console across your accounts.

AWS Console — IAM user permissions

I’ll give this user administration permissions as I am the admin and want to use this user across all my accounts. If you are creating a user for someone else in your organisation you may want to change the access policies as needed.

Switch Roles

Once you create this user you will be given a special log in link. Click through to this link and then log in as this user. One you log in you should see that the main account menu gives you access to a new option called Switch Role.

AWS Console — IAM user login with Switch Role

AWS Console- Switch Role

The Switch Role screen will prompt you to input the account number of the account you want to switch to. Add the account number of the Staging/Production account we created earlier.
In the Role*section we need to input the role name we created with those accounts *OrganizationAccountAccessRole. Then give the account display name and a colour and hit the Switch Role button.

This will save this role on your account and redirect you to it. You can repeat this step with any other accounts you want to be able to hop between.

AWS Console — Switch Roles

You’ll now be able to switch between accounts at the click of a button. Once you switch to an account you’ll clearly be able to see which account you are in.

AWS Console — Example Production Account

Now as a solo developer you’ll be able to sandbox your environments, have clean accounts to play with new technologies (like Sagemaker) and not have to worry about deleting resources or experimenting and breaking production code.

At an organisation level you will be able to create seperate root accounts for various parts of your organisation, and give users access to only the environments they need.