A github repo with related content is here.
One aspect of AWS Amplify is that it can easily provide a managed backend for an Amplify served frontend; there are two primary options: (i) a REST backend or (ii) a GraphQL backend. Obviously, for this simple case a GraphQL backend was not appropriate.
For a small project I’m working on, I wanted to set up content-oriented site comprising only of static content — Hugo was a natural choice. As I’m experimenting with AWS generally, I had a look at how AWS Amplify could be used to host it. Here, I discuss how I deployed the site to Amplify addressing these two points:
Content to test this out is provided in this repository…
In a previous post, I described how the widely use go-swagger module could be used in a Lambda/API Gateway context. A limitation of this solution, imposed by go-swagger is that it only supports Swagger/OpenAPI v2.0 (OpenAPI Specification 2 — OAS2); with OpenAPI v3.0 (OpenAPI Specification 3 — OAS3) support becoming increasingly important, it was interesting to explore how an OAS3 solution can be realised. One specific driver for this is that the AWS API Gateway HTTP API only supports OAS3; OAS2 is not supported.
This post, then, considers the following points:
AWS provides support for Swagger/OpenAPI defined REST APIs as well as a go runtime; however, it is not entirely clear how best to work with these, especially if you’re used to using go-swagger for go REST APIs in a non-AWS context. Here I describe how the API Gateway, go Lambda functions and the go-swagger module can work together. Two specific points are addressed here:
In a previous post, I described how I used Go on Frontend (FE) and Backend (BE) to create a simple Todo application: the FE was implemented using Vugu, the BE was implemented as Lambda functions on AWS — a secure Swagger defined API was used for FE/BE communication. Here, I wanted to consider asynchronous communications between FE and BE and hence I describe how I implemented the asynchronous variant of the Todo application.
Adding API security involved a complete frontend rewrite and some reasonably well documented changes to the AWS API Gateway based backend: AWS Cognito was chosen as the basis of the security solution as I was already working within the AWS ecosystem.
Limitations of vecty when supporting OAuth Flows
The previous frontend was written using the
vecty Go frontend framework; this is certainly a nice framework which proved (for me) a good…
In previous posts, I described how I put together a simple todo application which uses Go on the Frontend (FE) and AWS Lambda functions running Go on the Backend (BE). In the previous implementation, the FE-BE communication was done using the standard Go
net/http mechanisms — creating a request, calling the
Do() method and parsing the response. Although this worked, it was obviously suboptimal to have a Swagger defined API on the BE and not use this at all on the FE. Here I describe how I was able to use the Swagger auto-generated client code in the FE.
In previous posts (entry point), I described how it’s possible to use Go for both frontend and backend for a toy application. This initial work was basic and I wanted to delve a little deeper. Here I report on my experience getting a (slightly) more sophisticated frontend operational using Go.
As this was simply an experiment, I wanted to understand what was involved in creating a simple todo app with the…
I first decided to bring up a backed on AWS which offered a Swagger defined REST API to a data model persisted in Dynamodb realized with Lambda functions.
This of, course, is well trodden ground and there are many reports on how to do similar things; there is no point in repeating here what is already known. I will however note a couple of specific observations relating to this design which were not obvious to me when I started:
Tech Tinkerer, Curious Thinker(er). Lost Leprechaun. Always trying to improve.