Experimenting with Full Stack Development in Go — Part 3: Adapting the Frontend
The vecty repo provides a few examples of how to use the framework, one of which is exactly a todo application. This sample application uses Local Storage to store application state — I wanted to modify this to use the backend described in Part 2.
The required modifications were modest in general. The application is constructed to have a data model at its heart; in the sample application, this contains just the title of the todo and a boolean indicating whether it is completed — I modified this by adding a uuid for the todo and a creation date to understand a little bit about time handling.
After the basic data model changes were made, it was necessary to modify functionality relating to model updates: addition of new todos, updates to existing todos and deletion of todos all required interaction with the backend.
The basic interaction with the backend simply involved obtaining the list of defined todos on application initialization, POSTing new todos to tbe backend on creation, calling a DELETE method on the backend on deletion of a todo and supporting update of todos using a PUT method. The standard Go net/http library was used for this.
There were a couple of non-obvious issues:
- it was necessary to add a specific header to the HTTP request which gets picked up by the browser’s Web API which indicates that CORS can be used when accessing the backend.
- it was necessary to wrap the HTTP call in a goroutine — otherwise a deadlock would arise in the wasm application.
With these small changes, modification to todos in the frontend were posted to the backend with low latency. For more details see the code.
This specific solution does not have good error handling for cases in which there are larger latencies or error conditions arise on the backend. Similarly, it does not have functionality to differentiate between frontend state and confirmed/unconfirmed backend state. More analysis is required for good approaches to maintain this synchronization.
The application can be served from a public, CORS-enabled S3 bucket. Specific instructions to configure it are provided in the repo but the basic steps are as follows:
- modify the REST API endpoint in the application source
- build the wasm executable
- copy the correct
wasm_exec.jsfile from your go compiler - deploy to a newly created S3 bucket
Once this is done, your browser can be pointed at the S3 bucket and you can see the Todo application.
Some small reflections...
