we need to work on OpenAPI to document our endpoints then have it directed as docs.nimii.vercel.app. This should handle all the concerns with #16.

In the next couple of days, I will be migrating the hosted Nimi API to the new namespace: nimii.now.sh. Expect credentials and tokens to be rotated along with some integrations. There will be no redirect path from nimiii.now.sh to nimii.now.sh due to namespace differences.

Some ships like Minato Aqua or Universal Bulin appear in /api/ships and have their own ID but when using /api/ship/[id], requests lead to not found ressource errors. Needs investigation.
First thought : Might be a ship clan / class related issue.

title. is the documentation not implemented yet?

Currently master is very "hacky" in its current state, and won't be able to scale or properly move hosts. I discussed with @LeNitrous on possibly allowing this to run on serverless platforms but in order to do that, we need to rewrite the entire codebase from the ground up:

Todo List

• Use Next.js as basis for the API
• Finish porting over mixins, models, and remotes.
• Write new middleware (as most middleware code wrote for the previous codebase is not applicable for Next.js).

This would allow maintenance of the API to be much more easier and predictable as we would have less worries writing code that may have unpredictable behavior - and this would allow much more cleaner code in the future as well as TypeScript enforces strict typing discipline: something we would want as Nitrous and I come from C-based languages.

I found this repo accidentally from my Github's feed, and it's interesting. I'm trying to make an app for it, but how can I get the ship's image?

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.

I got confirmation from @LeNitrous that the API is not fully parity with the full version since the stats property is missing from the responses.

I reviewed the responses and I can confirm this was the case so this is a urgent task to implement it.

I'm aware this isn't really an issue or anything. I have someone working on a bot plugin that will utilize this API and we've been going back and forth on a few things since the wiki scrape is wholly unreliable and tends to break things.

We were trying to figure a bit out with the API endpoints and I was wondering if y'all had a Discord server or something.

Of the unofficial API's I've seen, this one appears to be the most feature-complete with many more endpoints than most.

While this project is open source under GNU General Public License, commercial use of this API is prohibited. This clause is non-negotiable.

This clause violates the GNU GPLv3 and can be removed by anyone who conveys a copy. The issue has been addressed in the FAQs for the GPL.

This is obviously not a high priority, but it should be corrected before any major release.