devalias.net https://www.devalias.net Follow me into the rabbit hole that is my mind and learn about topics including.. security, technology, efficiency, biohacking, health, personal growth and probably a whole lot more. en_GB Forming Serverless Clouds with AWS: CloudFormation, SAM, CDK, Amplify /devalias/2018/09/15/forming-serverless-clouds-aws-cloudformation-sam-cdk-amplify/ devalias 2018-09-15T00:00:00+10:00 /devalias/2018/09/15/forming-serverless-clouds-aws-cloudformation-sam-cdk-amplify/ Recently I have been playing around with a few little side projects, and trying out different ways of getting them IntoTheCloud(tm). If you know me, you know that I'm pretty big on increasing efficiency, reducing boilerplate/time to start, automation, infrastructure as code (IaC), and similar fun things.

With these explorations I have been looking to see how I can go from 'cool project idea' to having a PoC serverless application running InTheCloud(tm) with as little time, effort, boilerplate, and ongoing cost required; with the hope that if it is quick/easy enough, and the patterns simple enough, I will actually get around to hacking on more of my side projects (or it will be quicker and cheaper to get clients projects up and running).

AWS

For this particular exploration I have been playing around a lot in AWS (Amazon's Cloud), with a particular focus on serverless patterns. As you probably know, AWS is huge, basically runs a good chunk of the internet, and seemingly has a product line for every possible thing you could dream of.

Since I was looking to speed up my 'new project boilerplate', I decided to focus in on the following projects/services:

I'll go into a bit more detail on each of these below, but since I saw so much potential crossover/overlap between them, I opened a few issues on their respective repositories. You might find more interesting tips, tricks, and aspects in those threads too:

AWS CloudFormation

AWS CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your cloud environment. CloudFormation allows you to use a simple text file to model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts. This file serves as the single source of truth for your cloud environment.

Basically, CloudFormation is a bunch of JSON or YAML that defines all of the AWS resources/projects you want to use, how to configure them, and how to tie it all together. Then you can just push it ToTheCloud(tm), some kind of magic happens while you go make coffee, and you're done. It's AWS's basic Infrastructure as Code (IaC) service.

In reality, CloudFormation templates can VERY quickly get massively out of hand, huge, confusing, and pretty hard to cognitively reason about. It's great as an underlying technology layer.. but it isn't really optimised for human consumption (particularly the JSON format). Thankfully some of the other projects I will talk about a little later aim to solve that human interface problem.

Within CloudFormation there are a few high level concepts that it's good to be aware of:

  • Stack: This ties together all of your resources in an AWS Region into a single unit.
  • Nested Stack: A stack created within another stack. Allows you to seperate common patterns into their own templates and tie them all together.
  • StackSet: This ties together multiple Stacks, and allows you to manage them across multiple regions and accounts.

Since Stacks by themselves are single region, you can run into some weird problems depending on the services you want to use. For example, when I want to deploy my application in ap-southeast-2, but want to use AWS CloudFront (which runs in us-east-1) with a HTTPS certificate issued through AWS Certificate Manager, I can't natively do this within a single stack.

There are workarounds such as using custom resources to manage the deployment, or using a StackSet with exported outputs and Fn::ImportValue to deploy the related components across different regions; but sometimes it can take a little digging to figure out the best way to do it.

If you're interested in trying the Custom Resource approach, the following was how one person explained their implementation to me:

It's a bit complicated due to specifics of ACM certificate issuance. The general way it works is:

  • CloudFormation creates a custom resource that has the same "signature" as an ACM certificate. It takes the same parameters and has the same return values (Ref and attribute values).

  • The custom resource invokes a Lambda function in the account. This function requests a new certificate from ACM in us-east-1.

  • The Lambda function then sends a message to an SQS queue in the account. This queue is subscribed by the same Lambda function. The queue is effectively a "while" loop to reinvoke the function every 30 seconds to check whether the certificate has been issued.

  • Every time the Lambda function is invoked by the queued message:

    • If the certificate has been issued, the function responds with a success back to CloudFormation with the appropriate return values. The function returns successfully, which removes the message from the SQS queue.
    • If the certificate issuance failed, the function responds with a failure back to CloudFormation with an appropriate message. The function returns successfully, which removes the message from the SQS queue.
    • If the certificate is still awaiting verification, the function does nothing and throws an error. The error causes SQS to keep the message in the queue and retry 30 seconds later.

  • Meanwhile, the ACM certificate verification occurs (a human approves it via an email sent to the domain owner, or a DNS record is added to the domain to verify the certificate).

While it is pretty convoluted setup for a single project, I expect that if designed well this could be wrapped up into a simple open source/deployable component that everyone could make use of rather easily. Perhaps something for the AWS Serverless Application Repository or as a Launch Stack Button?

AWS Severless Application Model (SAM)

The AWS Serverless Application Model (AWS SAM) is a model to define serverless applications. AWS SAM is natively supported by AWS CloudFormation and defines simplified syntax for expressing serverless resources. The specification currently covers APIs, Lambda functions and Amazon DynamoDB tables.

AWS SAM (GitHub, Spec/Usage, Examples, Site, CLI, Templates) seems to have come about because using CloudFormation directly was just too verbose and time consuming for some of the more common serverless usecases. By wrapping these cases up in a simplified/abstracted way makes it easier to get started, and therefore more likely for people to use the serverless resources AWS provides. It similarly follows the CloudFormation model of defining your resources in YAML, and uses a translator (GitHub) to build the raw underlying CloudFormation template.

While AWS SAM seems great for these common usecases, there are definitely areas where you will need to fall back to using native CloudFormation (which you can thankfully use directly within a SAM template). There are also a number of areas where limitations in what SAM allows you to configure means you may not be able to use it's simplified abstractions. These are likely to improve over time as people run into the issues, and the maintainer team implements/improves features.

What is really nice is just how simple it is to get a new project off the ground:

  • Have a look at Get Started and install/upgrade the CLI: pip install --upgrade aws-sam-cli
  • Init your new application: sam init --runtime nodejs8.10 --name foo-app
    • There are MANY supported runtimes (sam init --help).. so choose your favourite: [python3.6|python2.7|python|nodejs6.10|nodejs8.10|nodejs4.3|nodejs|dotnetcore2.0|dotnetcore1.0|dotnetcore|dotnet|go1.x|go|java8|java]
  • Pull down your app dependencies: cd foo-app/hello_world && npm install
  • Run your API locally (sam local --help): cd ../ && sam local start-api
  • View your application in all of it's glory: http://127.0.0.1:3000/hello

If you have a look at the generated SAM template (template.yaml), you'll see that the entire stack is only ~45 lines (including newlines and comments), with the main function code only taking up ~15 lines. Not bad to get a PoC application running:

HelloWorldFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: hello_world/
    Handler: app.lambdaHandler
    Runtime: nodejs8.10
    Environment:
      Variables:
        PARAM1: VALUE
    Events:
      HelloWorld:
        Type: Api
        Properties:
          Path: /hello
          Method: get

Once we're ready to deploy this to the cloud, we have just a couple more commands to run:

  • Make sure our template is valid: sam validate
  • Package any external code and upload to S3 (bucket must already exist): sam package --template-file ./template.yaml --output-template-file ./packaged.yaml --s3-bucket FOO-PKGS-BUCKET
  • Deploy our stack: sam deploy --template-file ./packaged.yaml --stack-name Foo-App --capabilities CAPABILITY_IAM

Now if you're like me and enjoy writing your backend in Golang, then you may find the default template (sam init --runtime go1.x --name foo-app) a little lacking (eg. no dep, basic Makefile, etc). Thankfully we have the ability to pass a --location flag to tell it to use a different template project.

But how do we know what the template project should look like? Digging into the code we find the generate_project function, which accepts the location parameter. If the parameter is defined it will be used, otherwise it is looked up in the RUNTIME_TEMPLATE_MAPPING, which links the runtime you specified (eg. go1.x) to the template project to use (eg. cookiecutter-aws-sam-hello-golang). These templates are looked up in the _templates variable path, which after some digging I managed to locate in the repo at aws-sam-cli/samcli/local/init/templates/. There also appear to be a few more templates on the aws-samples GitHub.

Having a look at the Golang template project, it appears that these are Cookiecutter (docs) templates. So to make our own customised SAM Golang starter template, after installing Cookiecutter (pip install --upgrade cookiecutter), we can copy the existing template, make our desired changes, and save it somewhere useful for future use (such as GitHub). Then when we want to use it in a new project:

  • sam init --runtime go1.x --location gh:0xdevalias/TODO-cookiecutter-aws-sam-golang --name foo-app

While I haven't abstracted out my patterns into a custom starter template yet, this may be something I end up doing in future, so make sure to keep an eye on my GitHub.

AWS Cloud Development Kit (CDK)

The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation. The CDK integrates fully with AWS services and offers a higher level object-oriented abstraction to define AWS resources imperatively. Using the CDK’s library of infrastructure constructs, you can easily encapsulate AWS best practices in your infrastructure definition and share it without worrying about boilerplate logic. The CDK improves the end-to-end development experience because you get to use the power of modern programming languages to define your AWS infrastructure in a predictable and efficient manner. The CDK is currently available for Java, JavaScript, and TypeScript.

AWS CDK (GitHub, Changelog, Site, Reference, Examples: 1, 2) moves away from directly constructing raw YAML/JSON by hand, and takes more of a 'generator code' approach, providing a development kit of libraries that you can use to describe how your cloud infrastructure should look, connect, and interact. Once it's all defined in code, you can use it to generate the CloudFormation / AWS SAM YAML, deploy it to the cloud, and everything else you would come to expect from these sorts of tools.

The CDK is divided up into a number of libraries, with each representing an AWS service. Each of these libraries is broken up into two different levels of Constructs:

  • CloudFormation Resource: low-level constructs that provide a direct, one-to-one, mapping to an AWS CloudFormation resource, as listed in the AWS CloudFormation Resource Types Reference.
  • AWS Construct Library: handwritten by AWS and come with convenient defaults and additional knowledge about the inner workings of the AWS resources they represent. In general, you will be able to express your intent without worrying about the details too much, and the correct resources will automatically be defined for you.

Where possible you should be able to use the higher level constructs to get things done (and these will only get better over time), but it's nice to know that we have an easy way to drop down to the lower-level functionality when we need to. There also appears to be the ability to create new Construct libs (cdk init --list, template), so it's possible you could build your own custom construct abstractions with this. Another area for future exploration.

As is pretty standard by now, you define a stack which contains all of the features and services you want to use, then configure the environment to define where it should be deployed. You can define multiple stacks within your CDK App, which means we have a nice way to handle cross-region deployments. There is built in support for uploading assets (ref) that your application may require (eg. lambda code, etc), as well as applets for running custom code as part of your build (eg. compiling code/assets).

Getting started with a new project is pretty simple (note: if you don't have default creds configured, make sure to use AWS_PROFILE/--profile or things will hang):

When you're happy and think you're ready to deploy:

Following along from our previous AWS SAM example, we can create an equivalent example SAM function (ref) in ./bin/foo.ts with code such as the following:

import sam = require('@aws-cdk/aws-serverless');
import lambda = require('@aws-cdk/aws-lambda');

const helloWorld = new sam.cloudformation.FunctionResource(this, "HelloWorldFunction", {
  codeUri: "hello_world/",
  handler: "app.lambdaHandler",
  runtime: lambda.Runtime.NodeJS810.name,
  environment: {
    variables: {
      PARAM1: "VALUE"
    }
  },
  events: {
    HelloWorld: {
      type: "Api",
      properties: {
        path: "/hello",
        method: "get",
      }
    }
  }
});

Remember you will need to npm install any additional packages you need before you can use them:

npm i @aws-cdk/aws-serverless @aws-cdk/aws-lambda

Once we compile (npm run build) and synthesize (cdk synth), we can see we end up with equivalent YAML to our previous SAM example:

HelloWorldFunction:
  Type: 'AWS::Serverless::Function'
  Properties:
    CodeUri: hello_world/
    Handler: app.lambdaHandler
    Runtime: nodejs8.10
    Environment:
      Variables:
        PARAM1: VALUE
    Events:
      HelloWorld:
        Properties:
          Method: get
          Path: /hello
        Type: Api

While CDK is quite a new project (Aug 2018), we can already see that it is quite powerful to work with.

Amplify

Amplify is an open source project which is focused on mobile and web developers building applications. This consists of a library, UI components, and a CLI toolchain. The design follows a category based model allowing developers to perform advanced use cases with declarative client APIs so that they can focus on their application code (e.g. Auth.signIn() or API.graphql()). This allows developers to focus on their business use cases and less time on re-implementing the most common use cases around mobile or web app development (Auth flows, Storage and API interaction, Analytics, etc.) (Source)

AWS Amplify (GitHub) combines a number of different complementary aspects to simplify modern mobile and web development:

Of all of the projects I have explored today, this is the one I have the least experience with, so I may not have fully come to understand/appreciate the depth of it yet. In a bit of a difference from the previous projects, this seems to take more of a 'full-stack' approach to solving common application needs.

One of the nice things about the Amplify CLI is how it aims to provide simple menu-driven options for getting everything going:

  • Install the CLI: npm install -g @aws-amplify/cli
  • Init a new project: amplify init and follow the menu choices
⇒  amplify init
Note: It is recommended to run this command from the root of your app directory
? Choose your default editor: None
? Choose the type of app that you're building: javascript
Please tell us about your project
? What javascript framework are you using: react
? Source Directory Path:  src
? Distribution Directory Path: build
? Build Command:  npm run-script build
? Start Command: npm run-script start

Using default provider awscloudformation

Initializing project in the cloud...
..snip..
Your project has been successfully initialized and connected to the cloud!
  • Choose a category (feature) you want to add (amplify --help), and select it: eg. amplify function add
⇒  amplify function add
Using service: Lambda, provided by: awscloudformation
? Provide a friendly name for your resource to be used as a label for this category in the project: HelloWorld
? Provide the AWS Lambda function name: HelloWorld
? Choose the function template that you want to use: Serverless express function (Integration with Amazon API Gateway)
? Do you want to edit the local lambda function now? false
Successfully added resource HelloWorld locally.

At this point you should be able to see the generated files in ./amplify/backend/function/HelloWorld. Of particular note is the generated CloudFormation JSON (HelloWorld-cloudformation-template.json). While it is nice that it is automatically generated, using the JSON form, and not appearing to leverage SAM means that it ends up being quite a verbose file to cognitively reason about. I believe the intention is that you don't modify this directly (and I read somewhere that even if you do it may be overwritten?). If nothing else, it serves as a decent reference implementation for this kind of feature, that you could then translate back to your preferred method (eg. SAM/CDK).

Digging into the source, it appears these templates are located within the specific subpackage of the CLI, in the cloudformation provider (eg. the function template used above).

While currently there only appears to be a single 'provider' (amplify-provider-awscloudformation), language around the websites/repos implies that in future they would like to support additional providers, so it may be possible to implement CDK and/or SAM into this flow, for a 'best of all worlds' situation.

Implementing the most basic use case (function) as we did above isn't really where Amplify shines. For example, you can add an authentication system (JS Ref) to your backend with just amplify auth add, or a new GraphQL/REST api with amplify api add, and similar simplicity for other common features and patterns.

Moving from the backend infrastructure, Amplify also features libraries and UI components to consume these features in your application. For example, getting up and running with React (1, 2) can be as simple as:

create-react-app my-app
cd my-app
npm install --save aws-amplify
npm install --save aws-amplify-react

amplify init

And then a few little code changes to wire things into place.

As part of all of this, you get access to the UI Components, which should dramatically reduce the amount of boilerplate wiring up required to make use of these common application patterns.

I feel like I haven't even begun to dive deep enough into the frontend JS/UI component libraries to do them justice, so I will leave that as an excerise to the reader (or a future blog post).

As mentioned in previous sections, this is also quite a new project (Amplify (Nov 2017), CLI (Aug 2018)), so I'm sure things are going to get much better as time goes on.

Conclusion

We explored a number of different AWS serverless friendly projects and options, and how they may be able to be leveraged together synergistically, or to do similar things as each other. This is still an area I am actively exploring, and a lot of the projects are still quite young, so I'm excited to see what improvements and new efficient patterns come out of this! Maybe I will write a more specific follow up blog at some point detailing how I actually end up using some of these technologies in practice.

Where Next?

You could learn more about serverless and build a web app, put together a modern frontend with Create React App + Redux + Redux-Saga, design a serverless Golang backend with AWS SDK for Golang + Gorilla Mux + AWS Lambda Go Api Proxy, read more about Authentication with AWS Cognito, learn about GraphQL.. so many interesting things out there to learn about and play with!

What are you planning to build? Have any tips or suggestions? A story of how this helped (or hindered) you on a project? I'd love to hear about it in the comments below!

]]> Link Dump: Clearing Out My Todo List /devalias/2017/07/14/link-dump-clearing-out-my-todo-list/ devalias 2017-07-14T00:00:00+10:00 /devalias/2017/07/14/link-dump-clearing-out-my-todo-list/ I tend to stumble across a lot of interesting things as I travel across the web, and one of my productivity methods is to save the things I don't have time to check out immediately to Todoist. Unfortunately, time can be short, and life busy, so those 'thats an interesting article', 'i could use that tech thing' and 'that would be cool to blog about' things tend to just build up, and clutter my todo lists in an ever less efficient manner. So today lets clear some of that out!

This post will be a vaguely categorised link dump, and depending on if I remember why I saved it, maybe some notes too.

Looking over everything, there seem to be trends around development, security, privacy, blog/website, docker, tech, automation, branding and general performance/efficiency. Not really surprising when I think about the things that tend to interest me :)

Hope you find something interesting!

Development

Security

Privacy

Blog / Website / Social

Docker

Automation, Scraping, etc

  • Guide to Web Automation | Hackernoon
    • peterdemin/web-automation-2017: An attempt to cover state of web automation in 2017
      • This GitHub should have a bunch of other projects detailed in some of the (probably closed) issues
  • Scrapy: An open source and collaborative framework for extracting the data you need from websites.
    In a fast, simple, yet extensible way.
  • scrapinghub/portia: Visual scraping for Scrapy
  • Netflix/Scumblr: Web framework that allows performing periodic syncs of data sources and performing analysis on the identified results
  • Home Assistant: Home Assistant is an open-source home automation platform running on Python 3.

Tech

Branding

Alfred-esque

Windows

MacOS (OSX) on Windows

GitHub

Quantified Self

Performance, nootropics, etc

Interests, activities, etc

Gaming

Unsorted

]]> GraphQL: Why You Should Care /devalias/2016/09/07/graphql-why-you-should-care/ devalias 2016-09-07T00:00:00+10:00 /devalias/2016/09/07/graphql-why-you-should-care/ If you haven't yet come across GraphQL, it's kind of exciting stuff. It's a query language developed by Facebook, that basically lets you request exactly the data you need for the given task; no more, no less. Sounds good right?

Tell me more..

If you like to get into the nitty gritty of tech specs, you can head over to the GraphQL Working Draft (GitHub) to have a deeper read, then play around with the reference implementation in JavaScript.

Though if specs aren't really your style, check out 'Learn GraphQL' and give their free short course a run through. Should get you up to speed!

Ok. I'm in!

Excited? Want to dive into it? Need libraries for your particular tech stack? Head on over to the Awesome GraphQL list. You're bound to find what you need!

For my particular tech palette I was after something Scala'esque, maybe some Akka-HTTP to go with it. Seems I wasn't the only one! Sangria (GitHub) is a Scala GraphQL implementation. They even have an Akka-HTTP based example. Perfect! Throw in a little Relay support and this package is pretty much complete.

If you're looking for an all-in-one stack heading forward, I keep seeing a lot of good things posted by the team at Apollo Stack (by the Meteor team), so would most definitely recommend keeping an eye on them. They also post a lot of really good articles on their blog too.

For some further reading, make sure to check out:

GraphQL and Relay.. What about Redux?

A lot of things you'll read about GraphQL on the net will talk about it quite closely with Relay, and given they were both released by Facebook, and sort of designed to work together, it makes a lot of sense. That said, you most definitely don't need to use Relay to take advantage of the awesomeness GraphQL provides!

KADIRA states it pretty well in GraphQL vs Relay:

GraphQL provides a way to model and expose data in your app. You can use it on top of any kind of data source and use it with any kind of transport layer.

Relay is an efficient client-side data-fetching technology built for React. It talks to a GraphQL Schema to get data. Relay also has a server-side part that adds some features on top of GraphQL.

There is a bunch of talk about how Relay is currently a pain to use, but Facebook seems to be well aware of this issue and has future plans to make it much nicer to work with.

I think it's definitely worth keeping an eye on Relay in the future, but if you're not quite ready to jump in, you can always take advantage of the benefits of GraphQL while sticking to something like Redux (GitHub). For further reading:

GraphQL vs Falcor

So by now we should have a fairly good idea about what GraphQL is. So what's Falcor? This one comes from our friends over at Netflix. In essence, it turns all of your data sources into one giant JSON graph. Regardless of whether you're loading data remotely, have it cached locally, etc; you'll access it in the same way.

If you want to read deeper, I found these to be quite useful:

The consensus that I came to is that it seems to be on par with GraphQL in a number of ways, but is probably a bit easier to implement and a bit less powerful overall. Apparently you could even go so far as to query GraphQL with Falcor, but not the other way. For my purposes, I think I'll be sticking with GraphQL.

It's also worth noting that Facebook has been using various flavours of GraphQL for a few years now, whereas Netflix is yet to (or has only recently) started using Falcor in production.

API's: REST, HATEOS, Observables.. GraphQL!

I have read SO many articles over the years about the 'proper' way to design API's, and why styleX is so much better than styleY. With so much info out there, and so much conflicting advice (even within each supposed style), it's really easy to get stuck in analysis paralysis.

Greg Ziegan put together a nice little article talking about his progression along this path: from REST, through HATEOS, observables, etc; and how he ended up at GraphQL. Following on from this, Sashko Stubailo makes a pretty good argument about why GraphQL is "the next generation of API design".

While the benefits of a GraphQL-based API seem pretty obvious to me, it's not always feasible to jump straight into shiny new tech. Maybe you need to support legacy services, interact with 3rd-party API's, or allow other developers to consume your API without them having to learn the ins and outs of GraphQL. But thankfully, we don't need to pick one over the other!

The GraphQL team have a pretty good article on their blog about wrapping REST API's in GraphQL, starting purely with the client-side, and later moving it to the backend. This idea plays in SO well with some little side-projects I've been thinking about over the years, and how it could be used to help decompose and combine existing API's.

Conclusion

This is a scattering of the articles and things I have read through while learning more about GraphQL, and why it is so awesome. I definitely know it's a technology that I am super excited to start utilising in my future projects.

Have you come across any other awesome articles/tools related to GraphQL or similar? I'd love to hear about them! Let me know in the comments below.

]]> Shared Devices Need Account Switching /devalias/2016/08/31/shared-devices-need-account-switching/ devalias 2016-08-31T00:00:00+10:00 /devalias/2016/08/31/shared-devices-need-account-switching/ Living in share houses and using tech like the Apple TV has highlighted an annoying situation: so many apps these days want you to sign in to enable access, personalised features, etc; but most offer no good solution for when you share the device with other people.

There are some apps out there that handle this pretty well:

  • Plex allows you to switch between different users in your 'home', each of which can either be a fully independent account, or a 'managed user' that exists under the main account.
  • Netflix allows switching between different users under the one subscription. While this is ok.. it doesn't work so well for a share house. What if we each have our own Netflix subscriptions, but want to share the device without having to log out and back in to our own accounts?

And then there are so many apps that don't even seem to give the option, two of which immediately jump to mind for me:

  • YouTube let's you sign in to a single account, but no switching features save for logging out.
  • TED's app suffers from the same issue.

This could be fixed at the individual app level. It would be REALLY nice to see support for multiple account switching added to any app made for a device that could potentially be shared (Apple TV/etc, far less likely to be useful on an iPhone.. but it might be for some users) But this requires extra effort from every app developer out there. Perhaps a common framework could be developed to help support this.. but then making it generic enough to fit into everyone's different architectures would be a challenge.

An even better solution could be baked into the OS itself by Apple.. I boot up my Apple TV and am presented with an account chooser asking which particular registered user I am. If I haven't already logged in, there's the option for signing in to my Apple account to add myself as a new user. Once logged in, I'm presented with my own homescreen of apps, laid out to my own preferences, logged in to my own accounts, and saving my own personal data.

This poses some issues about duplication of apps between users, space requirements, etc. So a mid-ground could be allowing the owner/'master' user to control app installation, but then for each other user to be able to maintain their own stored data/signin status/etc.

What do you think? Is this a feature you'd use, or does it just seem like over-engineered bloat? Let me know your thoughts in the comments!

]]> Starting a New Web Application (Part 1): An Exploration of Options /devalias/2016/08/24/starting-a-new-web-application-1-an-exploration-of-options/ devalias 2016-08-24T00:00:00+10:00 /devalias/2016/08/24/starting-a-new-web-application-1-an-exploration-of-options/ Finding myself with some free time (and looking into starting a new project), I thought I might catch myself up on the state of web technologies, and what might be a good stack to work with.

The details collected here are most certainly not a complete layout of the entire landscape, and there will no doubt be leanings toward my personal tastes (reactive, api-driven, etc). You should use this more as a starter into your own deeper research than as a source of ultimate truth. With that out of the way, let's get into it!

Quicklinks

Frontend

The frontend is the pretty, interactive, main part that people will be seeing. You can have the most amazingly streamlined and perfect backend code, but noone's going to notice and love it without a strong frontend to back it up.

Frameworks

The days of raw JavaScript and jQuery selectors is long gone. We're looking for a nice, modern framework to help put together our frontend. Here's a little selection of some of our options:

As with most things, every man and his dog has their own opinion, so here are a few comparisons I found useful:

UI

Even if you like to go oldschool and code your site by hand in notepad/vi, you can't deny the ease/benefits of using a frontend UI framework.

Can't decide? Try some comparisons:

Scripting

Modern web apps live by the functionality they enable in the browser, and to do this, we need a JS-esque language. Your chosen frontend framework may sway your choice (eg. Angular (v2) has a strong preference for TypeScript), but ultimately, it's up to what you/your team feel comfortable with. With so many options out there, it's hard to pick.. And of course, you could always stick to plain JavaScript.. and with the new features coming in ES6 (eg. promises) and beyond, it might be a good choice.

  • Babel
    • A transpiler that lets you play with all the fun features of JavaScript ES6 and beyond, while maintaining compatibility with all of the older browsers.
  • TypeScript (GitHub)
    • "TypeScript is a typed superset of JavaScript that compiles to plain JavaScript"
    • If you're using Angular (v2) and like sticking to convention, this is the one for you.
  • CoffeeScript (or maybe v2)
  • Flow (GitHub)
    • While it's not a language unto itself, it does allow you the benefits of typed JavaScript without having to dive into something like TypeScript.
  • Scala.js
    • A little left field, this transpiles Scala code into JavaScript. While I probably wouldn't see myself using this as a main choice, it could make for some interesting reusability between front and backend.

Backend

My preferences for backend tech stacks lean heavily towards Scala and the Lightbend Reactive Platform these days, but I will make quick mention of some of the other options available.

Tooling

With the crazy mix of technologies and steps involved in modern web app development, it makes a ton of sense to tie it all together with some automation.

While a little different in purpose to the things mentioned above, getting everything nicely tested and deployed is always good:

Conclusions

Hopefully this has given you a decent starting point for figuring out what combination of technologies is going to work best for your next project. If you want to see the direction I've decided to go, make sure you read on in Part 2.

Have I missed something important? Not given love to your favourite stack? Got a cool pointer? Or just want to say hi? Let me know in the comments!

Updates

  • 2017-04-11 Added some more backend web frameworks, updated akka-http link, fixed some formatting
]]> Resolutions for 11111011100 [2012] /devalias/2012/01/04/resolutions-for-11111011100-2012/ devalias 2012-01-04T10:31:00+11:00 /devalias/2012/01/04/resolutions-for-11111011100-2012/ So here comes the obligatory post about my resolutions for 2012. In no particular order or level of detail:

  • Spend more time hanging out and chatting with friends. Those who are physically close as well as those far away; in person, on the phone and online; those who I am close to and those I should be closer with.
  • Put more time into coding/web design/development tasks with the aim of getting at least 1 app out this year.
  • Open source anything and everything I do that isn't a 'trade secret' (More on this to come later). Who knows what people will be able to find a use for. Also contribute back anything I can to open source projects I use.
  • Continue to read, learn and grow; be it in technical skill, learning about myself, or the world; and share what I learn with everyone and anyone who is interested. (Essentially open source whatever knowledge I gain)
  • Be more forward and take (calculated) risks even when they seem scary. (Talking to someone new/interesting/cute, giving that project a go, etc)

This one isn't a resolution so much as a goal but a notable thing to do in any case:

  • Ensure all of my hard drives utilise full disk encryption, using a strong password. ''The man' thinks he is too good these days, so why not stick it to him in a simple, fun, and secure way. (See the article on EFF.org)
]]>