Weekly Report: 15th July 2019
FrontierNav
- Unified data across every game
- Added data tables to every game
- Improved search performance
- Fixed various navigation bugs
- Progressed ideas on static generation
- Further improved security headers
#frontiernav
Posts tagged with #frontiernav. Visit the website.FrontierNav Search Performance
I've become more comfortable using Web Workers now. My first implementation of it for the Universal Search had a single global Worker searching across multiple indexes. Now, there's one for each index, created only when Search is activated and discarded after. I really can't tell what difference it's made since there aren't any Dev Tools that show individual performance metrics, but from an implementation point of view, it makes a lot more sense. There's no point having Workers waiting around, hogging resources.
FrontierNav Static Generation
FrontierNav is a JavaScript heavy application. So much so that loading it up without JavaScript will just show a warning. This is fine, since without JavaScript, FrontierNav becomes a bare bones wiki and there are plenty of better wikis around.
However, it does cause issues with search engines, social network sharing and others where they expect relevant information in the HTML on request. Google's search engine does use JavaScript, but others like Bing don't. Share a link to FrontierNav on Twitter and you'll just see a generic embed. This is a problem as it means FrontierNav isn't interacting properly with the rest of the web.
The proper solution to this is "Server-Side Rendering" (SSR). I've tried SSR before, but it doesn't work. A lot of the code wasn't made for it in mind so it just fails. To fix it would mean going through a lot of code and also making sure any future code works in both cases. It's a big investment.
An alternative I've been thinking of is to go through every page in a web browser and dump the HTML. I've tried it this week using Puppeteer to automate the process and... it works.
There are a few issues though: cache invalidation (as always) and deciding where to run it. It can't run server-side since it's using a whole web browser which is slow and eats up a lot of resources, so it'll need to run in parallel. Which in turn means it'll need to know which pages to cache.
Right now, the experiment is using the sitemap.xml to scrape FrontierNav. That works for the more simple pages. But pages like the Maps have potentially hundreds of elements, and dumping all of that into HTML will be ridiculous. These pages are the most likely to be shared on social media. I could strip the excess post-render, but then the solution becomes more complex, at which point SSR becomes more appealing again.
Running in parallel is also a lot of waste since the vast majority of pages won't be directly navigated to. I could make it more intelligent and have it use access logs to find the pages it should cache, but then it's caching after the fact so it'll always be one step behind.
Decisions. Decisions.
Weekly Report: 8th July 2019
I wrote this entire blog post and it was really long, so I broke it down into separate posts. This is just a summary.
FrontierNav
- Data can now be completely edited, but there's no way to save changes yet.
- Restricted which scripts and resources get to load on FrontierNav for security.
Linux
I spent a lot of time sorting out my workstation. It's a bit long and boring so I wrote a separate blog post on it.
Thanks for reading.
FrontierNav Security - CSP and SRI
I can't remember how I started going down this route, but I do know that as someone with multiple websites, I should be doing the most to ensure nothing malicious is being loaded onto my viewer's computer.
Actually, I do remember. I was looking into how FrontierNav can introduce an iframe-based, postMessage API to allow third-party integrations -- an exciting topic for another time. Loading iframes from other places is of course open to abuse, so I looked into securing it.
Weekly Report: 1st July 2019
Weekly Report is going to be a new series of blog posts giving an update of what I did in the current week. The aim is to share what I've done and also to help me appreciate and compare my acheivements.
While there will be FrontierNav-related updates in this series. They'll also contain unrelated updates related to my other projects. If you just want FrontierNav updates, you can wait for the monthly FrontierNav Progress Reports.
FrontierNav Report: June 2019
Changes in June
In case you're wondering, April and May don't have progress reports.
User Profiles
- You can now see a "Current Goal" for each game. This is like a per-game status so others know what you're focusing on.
- Game-specific user profiles show the current goal and recent posts.
- Global user profiles now list recent goal updates and posts.
- Avatars now have a customisable background colour.
User Settings
- Overhauled the user settings look and feel.
- Look and feel for all future forms will follow a similar style.
Community Feed
- Added list of recently active users
Universal Search
- Overhauled the search look and feel.
FrontierNav Editor
- Started implementing the editor, work in progress.
FrontierNav Report: March 2019
Changes in March
General
- Added types/labels/categories to search. For example, you can now search for "Blades" and see a list of all Blades.
- Improved behaviour of map features to reduce noise. Now certain features will only appear when you're on a relevant page. For example, when viewing an item page, you'll see features indicating the spawn points of enemies that drop the item.
- All map features now show a "check" icon when their target is marked as completed.
FrontierNav Report: February 2019
Changes in February
General
- Code improvements
- Improved developer tooling
FrontierNav Report: January 2019
Changes in January
Preview
General
- Added community forums for each game.
- Pretty basic right now, but more features will be added over time.