You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To show off the capabilities of our API, we need an app to act as our "tech demo", similar to how Project Polymer has a working Google Marketplace for Google merchandise.
However, the tech demo app isn't going to be half-assed in any way. We're going to develop in the same manner we developed the API - a full featured, production grade application everyone can enjoy.
Concept(s)
Architectural overview
We will be developing the viewer as a Progressive Web Application. This would allow us to leverage the user's web browser even more, so we can squeeze out every inch of performance we can to improve user experience.
We will be needing the help of web workers to achieve this.
The API Web Worker
To further leverage performance, we will be using a web worker with the sole purpose of doing what we did in the API lambdas: caching API responses then refreshing these caches when a change has been detected in the API.
In short, the API Web Worker has the following responsibilities:
Be the middleman between our API and the frontend.
Cache frequently visited routes then run hash comparison to see if we need to refresh the cache.
Leverage IndexedDB (the browser local Key-Value data store) for this purpose.
Connection Watchdog Worker
The watchdog worker checks for the availability of the API, it also checks if we're offline as well, this will instruct our API Web Worker to serve from cache instead of (hopelessly) trying to query API.
Asset Cache Worker
This worker does what API Web worker also does, only this is focused on caching assets. It's functionally similar and the watchdog worker will leverage this as well. Like the API web worker, we will be using IndexedDB as well.
Local Web Compression Worker
To reduce the footprint of the cache, we will be also introducing a local compression worker to compress the cache data in GZIP before going to the IndexedDB cache, it will also handle decompression. JavaScript-based compression workers won't cut it so we will have to use WebAssembly.
Designs
The "Index"
This is the current revision of the Index page. We're opting for a cleaner layout that is straightforward, no-BS, but still feels welcoming.
The cards you see here have different states. When hovered the cards will change color, and also scroll the background - paired with an equally cute 8-bit animation of a shipgirl I specifically hand selected to reflect what each category is supposed to reflect:
(Additional Notes: if you're the author of these 8-bit chibis, get in touch with me and let's discuss how you want to be credited!)
More designs are coming soon. I'll post them as I go.
The text was updated successfully, but these errors were encountered:
I've decided to make the designs in secrecy at the moment due to suspicions of someone stealing designs and code from us without any consent. I'll post the entire design once it's implemented fully.
To show off the capabilities of our API, we need an app to act as our "tech demo", similar to how Project Polymer has a working Google Marketplace for Google merchandise.
However, the tech demo app isn't going to be half-assed in any way. We're going to develop in the same manner we developed the API - a full featured, production grade application everyone can enjoy.
Concept(s)
Architectural overview
We will be developing the viewer as a Progressive Web Application. This would allow us to leverage the user's web browser even more, so we can squeeze out every inch of performance we can to improve user experience.
We will be needing the help of web workers to achieve this.
The API Web Worker
To further leverage performance, we will be using a web worker with the sole purpose of doing what we did in the API lambdas: caching API responses then refreshing these caches when a change has been detected in the API.
In short, the API Web Worker has the following responsibilities:
Connection Watchdog Worker
The watchdog worker checks for the availability of the API, it also checks if we're offline as well, this will instruct our API Web Worker to serve from cache instead of (hopelessly) trying to query API.
Asset Cache Worker
This worker does what API Web worker also does, only this is focused on caching assets. It's functionally similar and the watchdog worker will leverage this as well. Like the API web worker, we will be using IndexedDB as well.
Local Web Compression Worker
To reduce the footprint of the cache, we will be also introducing a local compression worker to compress the cache data in GZIP before going to the IndexedDB cache, it will also handle decompression. JavaScript-based compression workers won't cut it so we will have to use WebAssembly.
Designs
The "Index"
This is the current revision of the Index page. We're opting for a cleaner layout that is straightforward, no-BS, but still feels welcoming.
The cards you see here have different states. When hovered the cards will change color, and also scroll the background - paired with an equally cute 8-bit animation of a shipgirl I specifically hand selected to reflect what each category is supposed to reflect:
(Additional Notes: if you're the author of these 8-bit chibis, get in touch with me and let's discuss how you want to be credited!)
More designs are coming soon. I'll post them as I go.
The text was updated successfully, but these errors were encountered: