Most design decisions are based on the fact that I am cheap I am using the free tier of Firebase and this is for practice.

I just liked Neocities and I'm used to React.

Because I am dumb. I have used Postgres on another project, and then I wanted to use Firebase. But it turns out Firebase is bad for this type of statistical query.

If this site reaches 10,000+ seeds stored, I might began a migration and conversion to a Postgres / SQL provider.

If things are not submitting or the database is not loading, it's possible the quota was exceeded. I included a bit of error handling, but for the most part I don't think we will reach that quota.

There are 20,000 writes and 50,000 reads a day.

Each search results page costs 20 reads.

Each write, actually costs 4 writes and not 1, an update to global stats, raw submissions, items, seeds.

Global Stats: 1 document that keeps simple global stats.

Raw Submissions: All the raw submission data.

Items: List of items that appear for indexing.

Seeds: An index for some quick stats on each seed.

Showing "results 1 - 20 of 1,234" or "page 1 of 20" would be nice, but based on how Firebase prices reading from their database, I cannot show you that. The way the database is structured is 20 entries for 20 reads whether it's entries 1 - 20 or 9,990 - 1,000, but showing 1 - 20 of 1,234 results would become 1,234 reads, because Firebase "walks" through all the documents. If there is a way around that, please contact me.

Yes! It should be fairly easy to add a new category or seed based on how it's structured.

I did not include fertilizer use as a field because I do not think it affects the drop rates.