I have just released a new version of Moon Forge that uses web native auth and storage. Moon Forge is a playground for web audio synthesizers. The source code lives at GitHub - bgins/moon-forge: A forge for lunar instruments.
I have a couple of thoughts and reflections that I wanted to share on working with webnative.
Let’s make some comparisons
Adding web native auth and storage took considerably less effort than traditional alternatives would. Standing up a server would have meant writing a backend and maintaining it. A serverless approach would have required configuring at least four services (maybe more!) and writing a bit of code – less effort than a server-based approach, but still a decent amount of work to do it right with infrastructure as code and frontend integration.
By comparison, web native was dead simple. A handful of lines of code that live in the frontend and auth and storage were working! Remarkable, really, and hard to say a traditional approach even comes close.
Initializing web native for an existing user on page load takes longer than pulling a JWT from localstorage, and I would say this delay was the main thing I found myself working around. I am used to a loading state when retrieving data, but not during app initialization for an authenticated user. This led to some UI/UX considerations that I hope I have resolved well.
Bootstrapping app data
Moon Forge comes with a set of factory patches to get users started and show what is possible. The factory patches are fetched over HTTP.
I considered storing the patches in web native app storage after the initial fetch, but realized that it probably wasn’t worth it. What if I added new factory patches? I would need to fetch them and update web native storage. Maybe I could use a versioning system to determine when to update them? Indeed I could, but it all started to seem a bit complicated and I decided to stick to fetching factory patches every time.
It would be nice to have a web native folder that I could share with users that held the factory patches. Then web native would keep them up to date and fetching would not be needed.
Bulk reads from a folder
The most complicated code I wrote around web native was the code to load all of the files in a directory. Each read is asynchronous and it took some bulk promise resolution to collect them all up.
A method to retrieve all files in a folder and return them in array would be useful.
Community patches
I know. The sharing mechanisms are coming and I am super excited for them! A way for users to share with each other would be great, and a way for users to publicly share to anyone would also be nice.
Syncing between local and production environments
During development, I created a number of presets and stored them in my personal Fission account. I did not expect it, but once I released to production and signed in with Fission, all of my test patches showed up! This was like magic and I can see many benefits that might come of it.
Orienting users
Auth and storage will differ from what users are used to. I added the following notice to Moon Forge:
That’s just my first attempt at it, and I am interested to hear how other folks are approaching user education.
That’s all!
Thanks Fission team for making this all possible. It has been a pleasure using web native in my app, and I look forward to the future that it promises developers and users alike.