Intro
I made Wrapper.js a few years ago, to encapsulate devops processes and useful templates in a way that helps me prototype / deploy projects faster.
An example of this is the WebXR template that lets you spin up a real-time multiplayer experience with avatars.
There are some other templates Wrapper.js also has that lets you spin up for Amazon Auth, Ethereum Smart Contracts and Metaverse development.
The changes
When I first made Wrapper.js, I was primarily focussed on fast prototyping of exciting experiences that can be easily deployed and shown to people.
This is still the case now, but as I’ve worked on different projects over time, I’ve been working in a way that places more importance on maintainability.
This has ultimately led to me making several significant changes.
Focussed on Templates
In the old wrapper.js repository, I had the wrapper scripts located in src (which built into the build dir) and all the templates as separate repositories located in templates as subtrees.
This meant maintaining each template individually as well as the wrapper scripts in the main repo every time I wanted a change, in order not to break anything for the other templates.
Now the focus is on each template, all wrapper scripts are located in the scripts directory and all the source code for the repo is located in the src directory.
This makes maintaining and understanding how to use the repo much easier.
Directory Layout
Inside of each template of the old wrapper.js repo, would be a backend, devops and frontend directory – all logic is separated for each section of the repo.
The new layout has a client, server and shared directory.
The shared directory contains anything that is used by both the client and server (tieing both together where it makes sense).
‘Devops’, is integrated into all three directories and I will detail this furhter in a future post.
Backend Framework
In the previous repo, I used Serverless Framework and javascript to define various services that would be deployed.
This was very useful in some ways, but I also had to make a lot of manual configurations in order to get it to do what I wanted and it was far from ‘standardised’.
I have now moved to Nest as the Backend framework, which is a far more recognised way of developing Backend API’s.
Infrastructure as Code
Previously I was using Terraform to deploy all my infrastructure (apart from lambdas) and Serverless Framework to deploy the lambdas.
I did this because of how easy it was to do localhost development and deployments with Serverless, but it forced me to define the infrastructure in the above way.
Now I’ve committed fully to using Pulumi for the whole infrastructure.
This was a significant amount of work as it involved not only converting all my Terraform configuration, but also Serverless Framework too (which was by far way harder).
Now having done this, the infrastructure (and overall way devops process) is structured much neater and integrated into the client, server and shared directories – I’ll be making a post to detail this further in the future.
Typescript
Finally, previously the repository was written fully in Javascript, which was great when I was initially made Wrapper.js.
Now I’ve converted everything over to Typescript, which makes the actual developer experience far easier to work with.
Conclusion
In summary, Wrapper.js has changed so much as a result of this upgrade, so much so that I’ll be deprecating the old repository for Wrapper.js.
Going forward, my intention is to focus on building interesting open sourced projects that can be easily used and deployed by others.
The core of what Wrapper.js will still be there in these new repositories and will now be easily usable as part of that mono repo (instead of a separate CLI tool).
Looking forwards to building more stuff 😀
Creative Technologist