Commit graph

59 commits

Author SHA1 Message Date
861f3ab881 Fix bug in /api/readFromArchive
Well, two bugs: one with URL encoding, and another minor one where I forgot to return after ending the request with 404, oops lol :p
2022-10-13 14:02:37 -07:00
7bef1f3b9a Use imageUrlV2 in outfit thumbnails
Without this, 150x150 and 300x300 outfit thumbnails would fail to render new item layers where we didn't have an AWS image layer. Now, they correctly render the new stuff!

I tested this with the new "Spooky Stitches Markings" on the Grarrl, which has a blank image in AWS, but works correctly in the new code by loading the image from neopets.com!
2022-10-12 12:37:07 -07:00
a1844f76e0 Add /api/assetImageRedirect
Okay, this is gonna be a drop-in new backend for impress-asset-images.openneo.net, to enable Classic DTI to use the same images as DTI 2020!

This will enable us to stop generating images and uploading them to S3 just for Classic's sake, so we can turn those background processes off! And the new modeling script skips that anyway, so this is an important compatibility step for the new data that went out today!
2022-10-11 12:21:14 -07:00
29d9d498bf Use aws.impress-asset-images.openneo.net
We're gonna update impress-asset-images.openneo.net to perform redirects and stuff, so Classic DTI can start using the same images that DTI 2020 does.

That should enable us to stop relying on AWS for images, which is important because the new modeling script breaks that anyway :p but this will also let us turn off the image converters that run in the background all the time, and I'm excited for that too!
2022-10-11 12:19:39 -07:00
07e2c0f7b1 Add the /donate page
Just doing some house-cleaning on easy pages that need converted before DTI Classic can retire!
2022-09-25 08:05:38 -07:00
2b486ea218 New terms of use page
Remind me to link Classic DTI to this too tbh
2022-09-25 06:00:59 -07:00
34ceb6f5b4 Fix infinite-hang bug in /api/uploadLayerImage
Oops, Next.js has built-in request body parsing that happens automatically. So it was giving us a `req.body` string, and our code to read in the body and put it in a buffer was waiting forever!

Thankfully, it's much easier than I expected to turn that behavior off for just one route. Now it works like before, so our existing code works again, ta da!
2022-09-24 23:10:34 -07:00
832747b7a8 Set Content-Type and filename in readFromArchive
Before, we were using the ContentType from the S3 object, which was unreliable. This helps us behave better for query-string files!

We also add a filename via Content-Disposition for the files that auto-download and for the Save As case. Idk if this is super important exactly, but I feel like it'll be a lifesaver for anyone using this to get at a specific file for their own reference at any point! and it just seems polite lol
2022-09-24 22:23:45 -07:00
6d86e3e2a9 /api/readFromArchive to serve a backed up image
Okay so the funny thing is that my upload script is clearly like *super* not working lol, it's been running more than an hour now and still hasn't finished listening the files. So there's only actually a handful of files to test with here, from the `archive:create:upload-test` script!

But anyway, uhh once the archive is actually uploaded, this is a way to read it back! Mainly as a way to assure me that it's all saved correctly, but also as a potential backup for images.neopets.com if it goes down again sometime.
2022-09-24 12:44:13 -07:00
193e993095 A very hacky hack for SSR cache merges
Ok! I think I got it! It's very very nastly tho lmao! But this will merge in the new SSR-provided data before the new page can render, instead of having it sometimes make redundant network requests & show loading spinners in the meantime for data that Next.js already fulfilled for it.

Nasty nasty lil trick. But it seems to be working! Let's see how it does lmao
2022-09-15 04:45:44 -07:00
16c9e1a25d Simplify page title & SSR for saved outfit
Now we can just use our usual pattern: preload some GraphQL data, and render the title and such in the page component itself! Whew!
2022-09-15 04:03:51 -07:00
72211ae95a SSR for item trades page
I'm just moving through and using the new page title syntax, and getting some SSR in while I'm at it uwu
2022-09-15 03:30:14 -07:00
544a158f66 Oops, stop clobbering the Apollo client on nav
Ahhh right, a new `initialCacheState` value comes in on every navigation, so if our memoized Apollo client depends on that value, then it's gonna keep getting reset, and thereby dumping everything out of its cache. Rude.

This solution is clearly incomplete, the ideal would be to merge the SSR'd data into the cache each time. But it should be fine in practice I think, we already have good coverage of preloading stuff via GraphQL anyway!
2022-09-15 03:29:07 -07:00
c5bd2695f6 A bit of SSR for the item page
Always been a bit annoyed to have even the item name load in so weird and slow 😅 this fixes it to come in much faster!

This also allows us to SSR the item name in the page title, since we've put it in the GraphQL cache at SSR time!
2022-09-15 03:05:14 -07:00
2887d952de Fix /outfits/new init + add more SSR
Whew, setting up a cute GraphQL SSR system! I feel like it strikes a good balance of not having actually too many moving parts, though it's still a bit extensive for the problem we're solving 😅

Anyway, by doing SSR at _all_, we solve the problem where Next's "Automatic Static Optimization" was causing problems by setting the outfit state to the default at the start of the page load.

So I figured, why not try to SSR things _good_?

Now, when you navigate to the /outfits/new page, Next.js will go get the necessary GraphQL data to show the image before even putting the page into view. This makes the image show up all snappy-like! (when images.neopets.com is behaving :p)

We could do this with the stuff in the items panel too, but it's a tiny bit more annoying in the code right now, so I'm just gonna not worry about it and see how this performs in practice!

This change _doesn't_ include making the images actually show up before JS loads in, I assume because our JS code tries to validate that the images have loaded before fading them in on the page. Idk if we want to do something smarter there for the SSR case, to try to get them loading in faster!
2022-09-15 02:46:14 -07:00
38170bfbb2 Migrate home page to Next.js routing
I think that means we're done? :3 Gonna uninstall react-router-dom next.
2022-09-15 00:43:05 -07:00
eb602556bf [WIP] Migrate outfit page, with known bug
Okay so there's a bug here where navigating directly to /outfits/new?species=X&color=Y will reset to a Blue Acara, because Next.js statically renders the Blue Acara on build, and then rehydrates a Blue Acara on load, and then updates the real page query in—and our state management for outfits doesn't *listen* to URL changes, it only *emits* them.

It'd be good to consider like… changing that? It's tricky because our state model is… not simple, when you consider that we have both local state and URL state and saved-outfit state in play. But it could be done! But there might be another option too. I'll take a look at this after moving the home page, which will give me the chance to see what the experience navigating in from there is like!
2022-09-15 00:27:49 -07:00
5d28c36e8a [WIP] Migrate single-list page to Next.js routing
Hey we're getting real close! :3

I accepted a small bug here where clicking the breadcrumb to "Items X wants" won't scroll down if the page isn't loaded yet. (e.g. you landed on this list page first). If you came *from* the lists index page though, then when you go back your stuff will be there already, so you should be fine. (It might also happen if the page loads fast enough, which in prod it might do?)

Just gonna leave it for now, because the workaround would be a lot! (have the page re-check the anchor once it's done loading)
2022-09-14 23:18:13 -07:00
e1ebb0eb9a [WIP] Migrate trade lists page to Next.js routing
We're getting so close! :3

There was some shared components in `UserItemListPage` that needed updated too, even though the rest of the page isn't migrated yet.
2022-09-14 23:04:58 -07:00
750ca208f1 [WIP] Migrate item trade pages to Next.js routing
One little tricky thing here was moving the `[itemId].tsx` page into the folder as `index.tsx`! Because we didn't have subpages before but now we do!
2022-09-14 22:56:45 -07:00
17a7e2de81 [WIP] Refactor to renderWithLayout function
Okay, when I saw the recipe in the Next.js docs with `getLayout`, I was like "psh this API is so confusing, this should just be a component"

anyway now we see why it wasn't a component: the _whole point_ of it was to circumvent the usual React diffing algorithm's belief that two different components _can't_ ever share UI. But here we were, making different `layoutComponent`s that were meant to share UI, lol!

Anyway, if you just _return JSX in a function_, the React diffing algorithm never sees that it came from a different place, so it's generous when diffing them. Neat!

But I still changed the recipe's `getLayout` name to `renderWithLayout`, because it just confused me so much at first lol, I thought it was going to like, return a layout function? This is much clearer verbing to me imo
2022-09-14 22:50:56 -07:00
f1cfd1ac8f [WIP] Migrate /items/search to Next.js routing
Okay I actually screwed up the layouts thing a bit! Because right, they need to *share* a LayoutComponent in order to share the UI across the pages. This gets a bit tricky with wanting to change the margin, too. I'll address this with an upcoming refactor!
2022-09-14 22:44:48 -07:00
43ae248e87 Migrate /items/[itemId] to Next routing
The tricky part here was that `returnPartialData` seems to behave differently during SSR. On the page itself, this seems to cause us to always get back at least an empty object, but in SSR we can sometimes get null—which means that a LOT of code that expects the item object to exist while in loading state gets thrown off.

To keep this situation maximally clear, I added a bunch of null handling with `?.` to `ItemPageLayout`. An alternative would have been to check for null and put in an empty object if not, but this feels more resilient and more true to the situation.

The search bar here is a bit tricky, but is pretty straightforwardly adapted from how we did the layouts in App.js. Fingers crossed that it works as smoothly as expected when the search page is migrated too! (Right now typing in there is all messy because it hops over to the fallback route and does its whole separate thing.)
2022-09-14 22:26:59 -07:00
1dbc142f4f [WIP] Migrate /your-outfits to Next.js routing
This one was pretty boring! I was relieved to see the pagination changes seem to just work though 😅
2022-09-14 21:55:03 -07:00
02af99dded [WIP] Migrate /modeling to Next.js routing
Mostly easy, but with a link we needed to migrate in the `ItemCard` component! (I see one in `SquareItemCard` too, but I'll wait until it comes up.)
2022-09-14 19:52:10 -07:00
296d641c03 Merge branch 'main' into next-routing 2022-09-14 19:47:24 -07:00
04c4e0c1f3 Migrate /support/petAppearances to Next.js routing
This was only a little bit tricky! I also noticed the hanger loading indicator being weird without having a container Box, so I added one.
2022-09-14 19:46:57 -07:00
c22d1c2edc Oops I broke the wardrobe page lmao!
Missed a spot when deleting that extra `NextIndexWrapper` file! lol oops
2022-09-14 19:44:38 -07:00
1286b2e581 [WIP] Migrate /internal/assetImage to Next routing
This one is a bit trickier, because it doesn't use a page layout, and we had to make some fixes in OutfitMovieLayer! Nice to get a head-start on that though :3
2022-09-14 19:27:48 -07:00
65f3b9f819 [WIP] Migrate the conversion page
Another gimme!
2022-09-14 19:20:49 -07:00
eb8a0cf2a9 [WIP] Move Privacy Policy onto its own Next.js page
The first page moved over! Note that this broke navigation on the rest of the app, so don't deploy this until we're done!

The reason it broke was that we had to migrate GlobalHeader and GlobalFooter to the Next.js link & router stuff too, or else it crashed because it wasn't in a react-router-dom context.
2022-09-14 19:16:26 -07:00
4cd847f6ba Simplify references to PUBLIC_URL
The Next.js from react-create-app codemod automatically added this, just in case it mattered for us. It doesn't! I'd rather just avoid the code complexity.
2022-09-14 18:44:43 -07:00
43089dd4ab Switch to Chakra's standard ColorModeScript
We'd previously emulated this tag's functionality in create-react-app via copy-paste, but now we can just use it directly the standard way!
2022-09-14 18:43:51 -07:00
8cd45d7082 Move a lot of App.js stuff into Next's _app.tsx
Just sorta idly poking at what it would take to make our Next setup a bit more normal. To start, I'm putting things in more of the normal place, and eyeing what it would take to switch to Next's built-in routing! So now `App.js` is pretty much entirely a routing file, potentially to be deleted once we move 🤔
2022-09-14 18:38:58 -07:00
26d7f4220a Fix TypeScript errors in pages dir
Idk why Next made me these files in a way that created React errors but ok! Maybe it was because we didn't have `pages` in the `includes`, so my editor was using the default tsconfig instead of this one?
2022-09-14 18:04:10 -07:00
4c9dbf91fb Use latest ~owls NC trade values API
They're moving away from the bulk endpoint to individual item data lookups, so we're updating to match!
2022-09-04 01:35:05 -07:00
41efe05be4 Manually disambiguate Butterfly Dress from ~owls
There are two Neopets NC items named Butterfly Dress! ~owls disambiguates them by calling one of them "Butterfly Dress (from Faerie Festival event)".

It'd be a bit more robust to cooperate with ~owls t o get item IDs served up in this case, but it's not a big deal esp. for only this one case, so like… this is fine!
2022-08-16 13:59:10 -07:00
240a683e71 Finish wiring up ~owls data
Hey nice it looks like it's working! :3 "Bright Speckled Parasol" is a nice test case, it has a long text string! And when the NC value is not included in the ~owls list, we indeed don't show the badge!
2022-08-15 23:57:33 -07:00
16b86fc65e Playing with using OWLS Pricer data
This isn't a partnership we've actually talked through with the team, I'm just validating whether we could reuse our Waka code if it were to come up! and playing with it for fun 😊
2022-08-15 18:39:29 -07:00
7373a46bd7 Tweak the pattern for S3 asset URLs
Dice makes a good point! This is slightly clearer about what the valid set of sizes are! Why the hell not be slightly clearer! :3
2022-08-03 15:12:42 -07:00
c608f01a7a Accept more HTTPS layer URLs in /api/outfitImage
I also added some docs for what these patterns are! Mainly because I wanted to add that TODO note, but felt it needed more context to make sense!
2022-08-03 15:06:38 -07:00
cc9a540cec Fix Juppie Swirl bug in /api/validPetPoses
Oops, the new Juppie Swirl color has ID 114, and there's no released color #113 yet. But our `/api/validPetPoses` code, when deciding how large to make the byte array, uses the _number_ of colors in the database.

This meant that, when Juppie Swirl was released, there wasn't a 114th slot allocated, and the loop stopped at color ID #113—so the new Juppie Swirl color #114 wasn't included in the results. This made it impossible to select Juppie Swirl as a starting color. (You could, however, model a Juppie Swirl Chia, and the wardrobe would load it successfully; and you would see the color/species picker with the correct options selected, but in a red "invalid" state.)

Now, we instead use the largest ID in the database to determine the size of the array. This means Juppie Swirl is now included correctly!

There would be network perf implications if the color IDs were a sparser space, but it's dense enough to be totally fine in practice. (But let's not release an April Fools color #9999 or anything!)
2022-02-23 00:01:10 -08:00
19f1ec092e Turn on Honeycomb instrumentation again
Well, instrumentation seems to be working fine again! The bug we ran into during commit e5081dab7e is gone. Cool!

I want to be able to see what's making the new box slow. My hypothesis was (and it seems to be right) that communication with the database on the Classic DTI server is slow.

But now that they're on the same Linode account and region, I think I can set up a private VLAN to make them muuuch faster. We'll try it out!
2021-11-26 23:41:22 -08:00
5039371a1d Simplify the page pool
Yeah ok, let's just run one browser instance and one pool.

I feel like I observed that, when I killed chromium in prod, pm2 noticed the abrupt loss of a child process and restarted the whole app process? which is rad? so maybe let's just trying relying on that and see how it goes
2021-11-13 02:27:24 -08:00
0c2939dfe4 Use Puppeteer instead of Playwright
We used Playwright in the first place to try to work around a Vercel deploy issue, and I'm not sure it really ended up mattering lol :p

But yeah, I'm putting the new Puppeteer code through the same prod stress test, and it just doesn't seem to be getting into the same broken state that Playwright was. I'm guessing it's just that Puppeteer has more investment in edge-case handling? (There's also the fact that we're no longer running things as root, which could have been a fucky problem, too?)
2021-11-13 02:16:58 -08:00
20fff261ef Switch to a small page pool
Hmm I am really not managing to keep the processes under control… maybe I'll try Puppeteer and see if it's just a bit more reliable??
2021-11-13 01:45:27 -08:00
18bc3df6f4 Use browser pooling for /api/assetImage
I tried running a pressure test against assetImage on prod with the open-source tool `wrk`:

```
wrk -t12 -c20 -d20s --timeout 20s 'https://impress-2020-box.openneo.net/api/assetImage?libraryUrl=https%3A%2F%2Fimages.neopets.com%2Fcp%2Fitems%2Fdata%2F000%2F000%2F522%2F522756_2bde0443ae%2F522756.js&size=600'
```

I found that, unsurprisingly, we run a lot of concurrent requests, which fill up memory with a lot of Chromium instances!

In this change, we declare a small pool of 2 browser contexts, to allow a bit of concurrency but still very strictly limit how many browser instances can actually get created. We might tune this number depending on the actual performance characteristics!
2021-11-12 23:35:30 -08:00
3ec0ae7557 Use localhost in /api/assetImage
Just another VERCEL_URL removal!
2021-11-12 22:08:06 -08:00
0a81f07849 Remove Waka values
The motivation is that I want VERCEL_URL and local net requests outta here :p and we were doing some cutesiness with leveraging the CDN cache to back the GQL fields. No more of that, folks! lol
2021-11-12 22:06:50 -08:00
991defffa1 /api/outfitImage makes direct GQL queries
Previously we were using HTTP queries to keep individual function bundle sizes small, but that doesn't matter in a server where all the code is shared!

The immediate motivation is that I want /api/outfitImage requesting against the same server, not impress-2020.openneo.net. For other stuff I'm probably gonna fix this by replacing VERCEL_URL with something else, but here I figured this was a change worth making anyway.
2021-11-12 21:53:22 -08:00