The 2020 Next.js rewrite, now being merged into impress!
Matchu
92a4fd4808
We've been serving images directly from `impress-asset-images.s3.amazonaws.com` for a long time. While they serve with long-lasting HTTP cache headers, and the app requests them with the `updated_at` timestamp in the query string; each GET request still executes a full S3 ReadObject operation to get the latest version.
In the past, this was only relevant to users on Image Mode, not Flash Mode. But now that everyone's on Image Mode, this matters a lot more!
Now, we've configured a Fastly host at `impress-asset-images.openneo.net`, to sit in front of our S3 bucket. This should dramatically reduce the GET requests to S3 itself, as our cache warms up and gains copies of the most common asset PNGs.
That said, I'm not sure how much actual cost impact this change will have. Our AWS console isn't configured to differentiate cost by bucket yet—I've started this process, but it might take a few days to propagate. All I know is that our current costs are $35/mo data transfer + $20/mo storage, and that outfit images are responsible for most of the storage cost. I hypothesize that `impress-asset-images` is responsible for most of the reads and data transfers, but I'm not sure!
In the future, I think we'll be able to bring our AWS costs to near-zero, by:
- Obsolete `impress-asset-images`, by using the official Neopets PNGs instead, after the HTML5 conversion completes.
- Obsolete `impress-outfit-images`, by using a Node endpoint to generate the images, fronted by a CDN cache. (Transfer the actual data to a long-term storage backup, and replace the S3 objects with redirects, so that old S3 URLs will still work.)
I hope this will be a big slice of the costs though! 🤞
(Note: I'll be deploying this on a bit of a delay, because I want to see the DNS propagate across the globe before flipping to a new domain!)
|
||
|---|---|---|
| .github/workflows | ||
| .husky | ||
| .vscode | ||
| api | ||
| cypress | ||
| public | ||
| scripts | ||
| src | ||
| .gitignore | ||
| cypress.json | ||
| LICENSE.md | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| vercel.json | ||
| yarn.lock | ||
Dress to Impress 2020
This is a rewrite of the Neopets customization app, Dress to Impress!
It's a React app, built with create-react-app, running on Vercel, JAMstack-style.
The motivating goals of the rewrite are:
- Mobile friendly, to match Neopets's move to mobile.
- Simple modern tech, to be more maintainable over time and decrease hosting costs.
If you want to contribute, please reach out to Matchu! This repository is almost shareable, but the main limitation is that we currently run even our development server against the production database, and those credentials are private. But we can change that if there's interest!
Architecture sketch
First, there's the core app, in this repository.
- React app: Runs on Vercel's CDN. Code in
src/app. - API functions: Run on Vercel's Serverless Functions. Code in
apiandsrc/server.
Then, there's our various data storage components.
- MySQL database: Runs on our Linode VPS, colocated with the old app.
- Amazon S3: Stores PNGs of pet/item appearance layers, converted from the Neopets SWFs. (Once Neopets releases HTML5-compatible assets for all their items, we can hopefully remove this!)
Finally, there's our third-party integrations.
- Auth0: For authentication. Data imported from our old OpenNeo ID auth database.
- Honeycomb: For observability & performance insights on the backend.
- Discord: For logging Support users' actions to a private Discord server.
- Neopets: We load pet data from them! And plenty of assets!
Notable old components not currently included in Impress 2020:
- Elasticsearch: Used for lightning-fast item search queries. So far, we're finding the MySQL queries to be fast enough in practice. Might consider using some kind of fulltext query engine if that doesn't scale with more users!
- Resque: Used to schedule background tasks for modeling and outfit thumbnails.
- Outfit thumbnail generation: Used for outfit thumbnails in the app. I'm wondering if there's a way to get away with not doing this, like just rendering the layers... but I suppose if we want a good social share experience, then we'll probably want this. Maybe we can generate them on the fly as API requests, instead of adding a data storage component?
- Memcache: Used to cache common HTML and JSON snippets. Not yet needing anything similar in Impress 2020!
- The entire old Rails app! No references to it in here, aside from some temporary URL links to features that aren't implemented here yet.