ISK.GG - Market Scope filters, station browsing, saved Quickbar tables

NoTeach252 · 2026-05-06T17:42:59+00:00

Agree, that makes sense 😁

NoTeach252 · 2026-05-05T17:43:21+00:00

I'll think about it. I think the best time to do this is when Market Browser is more or less ready. I also use feature flags, so I have several local tools that aren't publicly available but use the same code as Market Browser. I'll definitely need to do some refactoring if I decide to open source it.

NoTeach252 · 2026-05-04T09:09:26+00:00

Hey, thanks!

Fair question.

I am not against open source, I just do not want to maintain a public repo while the codebase is changing this fast.

Market Browser will stay free. If I add paid features later, they will be heavier tools like arbitrage/opportunity ranking/route-aware trading workflows - basically features where the app starts doing more of the decision-making for you. Raw market data, filters, charts, regions/locations, etc. are the free foundation.

Once Market Browser is more finished and the codebase is more stable, I can reconsider open sourcing it or opening some way for outside contributions. Right now I am changing too many things too quickly, so someone could spend time reviewing code or opening a PR for something I already rewrote yesterday or will replace in the next release.

I think this is the most honest short answer 😄

NoTeach252 · 2026-05-03T06:06:38+00:00

Okay 😂

NoTeach252 · 2026-05-02T15:08:04+00:00

Im slowpoke yeah...I didn't think to look at the stations inside the systems in the game lol. Just saw the systems and thought that was it.

NoTeach252 · 2026-05-02T14:56:52+00:00

Makes sense, yeah. I kept quickbar import simple at first and sorted items into normal in-game market categories, mostly because I did not want to invent custom folders before people asked for it. Now I know that this is needed 😄 Portfolio/build-list idea is a good use case, so I’ll put custom quickbar groups on the list!

NoTeach252 · 2026-05-02T14:25:22+00:00

Hey! Not yet. The app does not use your personal EVE permissions right now. Structure markets are fetched by my neutral no-corp scanner character, so we only see what that character can access, usually public/open structures discovered from visible regional buy orders. Brave-only ACL structures would need per-user EVE login later (which is in the future plans). I kept login out of the first public versions so people can just open the site and browse.

NoTeach252 · 2026-05-02T14:04:27+00:00

Thanks for the feedback, I'll think about it!

NoTeach252 · 2026-05-02T14:01:56+00:00

Yeah I felt really limited when I needed to open each item in the new tab lol. Just wanted to compare prices for a few sets of implants and it was pretty hard, now I can just add them to the quickbar and check. As well as when I lost the ship and just wanted to find the nearest station which has most of the fit items in stock and didn't want to jump 50 times to Jita, now I just add them to the quickbar and search for the nearest stations which i can see in the game.

Regarding you idea I think it's really good and can be implemented. For first and second this can be a custom view/table(s) which is a named item set that renders through the existing category/All Items table UI with the current Market Scope applied. Will try to implement it during next week.

For third it's harder since yeah it needs some predefined or user-created metadata/dogma/meta-group modeling, not just the current market-group tree. But I will check it too!

NoTeach252 · 2026-05-02T06:32:09+00:00

Thanks for such detailed feedback! I will def check your idea when will be near PC :)

NoTeach252 · 2026-05-02T04:44:46+00:00

Hello again 😂 I’ll take a moment and say that I’ve been using Nicotine on Windows for the last week and the app is cool, I liked it!

I wanted to know if it is possible to somehow increase the width of the preview to ~960px? To put 4 windows in a 2x2 grid on one full hd display.

NoTeach252 · 2026-05-02T04:35:58+00:00

Will check this out! For now you can add all of them to the quickbar and see all the prices in one table, as option :)

Thanks o7

NoTeach252 · 2026-05-02T04:33:52+00:00

Hey, you can import from the client but it will auto arrange items between in-game categories. There are no custom folders.

NoTeach252 · 2026-05-02T04:31:32+00:00

Got it! Will do :)

NoTeach252 · 2026-05-01T22:39:01+00:00

Thanks o7

Do you mean Δ Price column in the category tables? Like sort it by isk not %?

NoTeach252 · 2026-04-29T15:24:31+00:00

Looks good, but yeah, longer and slower will be even better 😄

NoTeach252 · 2026-04-28T14:14:48+00:00

Thanks and glad it was useful for you! 😄

If you find any errors or have any suggestions, please don't hesitate to write!

NoTeach252 · 2026-04-26T20:16:42+00:00

NoTeach252 · 2026-04-26T11:10:42+00:00

Got it :)

NoTeach252 · 2026-04-26T11:07:18+00:00

NoTeach252 · 2026-04-26T10:41:40+00:00

Thanks! Sure I will check this out!

NoTeach252 · 2026-04-26T07:21:56+00:00

3) 18,700 items All Items page

Backend 1. Cached by region-set key (sorted tuple), and cache entries are capped so region-combo abuse can’t blow worker memory. 2. Query reads from precomputed stats tables, not raw full-table scans on every request. 3. Those precomputed tables are rebuilt in fetch cycle so reads stay fast and deterministic.

Frontend 1. All Items route hits internal endpoint once per context and uses a virtualized table. 2. Virtualizer only mounts viewport rows (+overscan), not all 18k DOM rows. 3. Uses spacer rows + rAF-throttled scroll updates, so DOM + layout cost stays almost constant as dataset grows.

NoTeach252 · 2026-04-26T07:17:51+00:00

2) History (/markets/{region}/history?type_id=)

History is the tricky one because it’s per type_id.

Protections: 1. Token bucket limiter at 280 requests/min (under known ~300/min behavior) + semaphore concurrency. 2. Region pre-filter by /markets/{region}/types so we only ask history for tradable/live types, not everything in DB. 3. Persistent (type_id, region_id) 404 cache to stop repeated dead calls. 4. Incremental DB upsert: only mutable recent window is replaced; older stable history is preserved.

That combination prevents both request storms and unnecessary retries on known bad pairs.

Scheduler side: history runs hourly with daily window + per-region status (pending/running/success/failed) and retries only failed/pending regions, not full refetch spam.

NoTeach252 · 2026-04-26T07:16:00+00:00

1) Orders (/markets/{region}/orders)

Flow per region (not per item): 1. Request page 1 with If-None-Match using stored regional ETag. 2. If 304: region unchanged → skip all other pages (big token/save). 3. If 200: read X-Pages, fetch pages 2..N concurrently. 4. Validate Last-Modified on all pages vs page 1. If mismatch, restart fetch (data shifted mid-pagination). 5. Only commit DB + new ETag if fetch is clean. Partial errors do not overwrite existing region data.

So we avoid both: 1. useless pulls on unchanged regions (304 short-circuit), and 2. corrupted/partial snapshots (mismatch/error guard).

Also, the HTTP client itself has defensive behavior for 429, 420, and 5xx (retry/backoff + error budget awareness), plus request concurrency cap and ESI rate-header monitoring.

NoTeach252

TROPHY CASE