<commit_before>---
layout: post
category : projects
title: "Commerce Wizard PoC"
tags : [commerce, cloud, poc, angular2, aws, apigateway, cloudformation]
---
{% include JB/setup %}

I've had a bit of a play at building my [Commerce Wizard](http://blog.maxieduncan.co.nz/projects/2017/07/27/commerce-wizard) creating a simple [Proof of Concept](http://commerce-wizard.s3-website-eu-west-1.amazonaws.com).  It's functional enough as a PoC and you get the idea but there's plenty more that could be added and refined; I've also only put together a minimal set of data to demo it. Chose Angular2 as the framework because it seemed like a good opportunity to learn something new and I've got to know CloudFormation a bit better.

It certainly seems like a viable idea though the benefits of the actual application are pretty limited. Any real advantage would be gained by building up a library of reusable CloudFormation templates rather than in the actual wizard itself, though it certainly does make them easier to combine together.

As with most cloud services, encountered some limitations worth noting along the way (and I'm only scraping the surface of what's available):
* limit of 60 input parameters per template, not necessarily an issue (and certainly not in the existing example) but if you're§ trying to combine a range of disparate services it could require the template to be broken up into pieces (probably linked together by CloudFormation outputs).
* API Gateway swagger definitions need to inline for the CloudFormation parameters and constants to be resolved. If you need access to these variables and attributes then referring to a swagger definition stored in an S3 bucket won't work (took a while to work that one out).

You'd need to put some thought into how you'd handle different environments. As an example, my [API First CMS](http://blog.maxieduncan.co.nz/projects/2017/03/27/api-first-cms) currently has the DynamoDB table names hardcoded in the Lambda functions. If you want to create distinct environments - as you would - then some effort would need to go into the CloudFormation templates to ensure that they can be uniquely identified.

There's also a question over how you'd handle data that I haven't really looked into. It depends on the context of course, but I'd expect you'd probably copy any relevant data to a bucket and then as outputs list the commands that need to be run to import that data, or maybe just the file locations. Potentially the execution of the CloudFormation template and the loading any data could even be run directly from the wizard.
<commit_msg>Updated S3 bucket hosting PoC<commit_after>---
layout: post
category : projects
title: "Commerce Wizard PoC"
tags : [commerce, cloud, poc, angular2, aws, apigateway, cloudformation]
---
{% include JB/setup %}

I've had a bit of a play at building my [Commerce Wizard](http://blog.maxieduncan.co.nz/projects/2017/07/27/commerce-wizard) creating a simple [Proof of Concept](http://commerce-cloud-wizard.s3-website-us-east-1.amazonaws.com).  It's functional enough as a PoC and you get the idea but there's plenty more that could be added and refined; I've also only put together a minimal set of data to demo it. Chose Angular2 as the framework because it seemed like a good opportunity to learn something new and I've got to know CloudFormation a bit better.

It certainly seems like a viable idea though the benefits of the actual application are pretty limited. Any real advantage would be gained by building up a library of reusable CloudFormation templates rather than in the actual wizard itself, though it certainly does make them easier to combine together.

As with most cloud services, encountered some limitations worth noting along the way (and I'm only scraping the surface of what's available):
* limit of 60 input parameters per template, not necessarily an issue (and certainly not in the existing example) but if you're§ trying to combine a range of disparate services it could require the template to be broken up into pieces (probably linked together by CloudFormation outputs).
* API Gateway swagger definitions need to inline for the CloudFormation parameters and constants to be resolved. If you need access to these variables and attributes then referring to a swagger definition stored in an S3 bucket won't work (took a while to work that one out).

You'd need to put some thought into how you'd handle different environments. As an example, my [API First CMS](http://blog.maxieduncan.co.nz/projects/2017/03/27/api-first-cms) currently has the DynamoDB table names hardcoded in the Lambda functions. If you want to create distinct environments - as you would - then some effort would need to go into the CloudFormation templates to ensure that they can be uniquely identified.

There's also a question over how you'd handle data that I haven't really looked into. It depends on the context of course, but I'd expect you'd probably copy any relevant data to a bucket and then as outputs list the commands that need to be run to import that data, or maybe just the file locations. Potentially the execution of the CloudFormation template and the loading any data could even be run directly from the wizard.

{'fraction_non_alphanumeric': 0.048719908291937335, 'fraction_numerical': 0.008979747802827665, 'mean_word_length': 4.592948717948718, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '980840', 'n_tokens_mistral': 1313, 'n_tokens_neox': 1216, 'n_words': 792}