hey everyone! i’ve been thinking through this project in notes (and in my head) for a little while now, and just got started putting things down in code starting friday or so.

i’m working on fabrica, an overengineered parts library/search engine for robotics teams. currently i’ve structured out how to code static database generation, decided on repository structure, and scaffolded tooling and helper functions for later use, and am now working on a data scraper for goBILDA parts. it’s not the fancy website stuff, but getting all of the data was something i wanted to get down first.

this is a passion project, and am taking my time with everything so i’ve turned off AI features.

i. introduction

so over the 2025-26 season i’ve had to deal with the onshape for ftc plugin and left unsatisfied. its search performance was shoddy, it occasionally went out, the parts library was limited, and there was unintuitive duplication for parts like channel and shafting. as i explored the frc cad ecosystem, i came upon MkCAD, and now FRCDesignApp. i liked how it was open source, the search function worked a lot better, yet… i felt like it was inadequate of a solution.

why not frcdesignapp? well, because i wanted to make one that generates the database at build-time, i wanted semantic type-as-you-search, and i had ambitions to—well, aside from having it under the ultro moniker—integrate it with a future inventory system. i also wanted it to be written in full stack typescript rather than a python backend, since it would allow for further front-end optimizations like SSR and asynchronous data streaming with type safety.

design goals

1. search should work with many different types of queries. starting with part numbers, a search for “1120-0014-0360” should return with that sku. “14 hole gobilda u channel” should return first a 14-hole regular u channel, then low side, then mini low side u channel, then 13 and 15 hole counterparts; “gobilda c channel” should return low side u channel, then mini low-side; “bearings for gobilda” should return bearings not only from gobilda, but also 14mm flanged bearings from mcmaster, etc etc. i want the search experience to far surpass other sites’ catalog websites so you’re incentivized to stay in one place and not have to go to mcmaster-carr or west coast products or gobilda for their search experience.
2. search should be as fast as humanly possible. i’ll get into the architectural implications of that in a bit, but results should show up as you type, should still be fast on shoddy internet connections, and should render results quickly to the screen. in the case of URL-inputted queries, the page should partially render, with the background UI fully loaded and the search results asynchronously given; SSR should not be blocked by result fetching.
3. search should be programmatic — you can access product information through a REST API, perhaps even GraphQL for getting a bulk list of relevant products. this allows the app to integrate into inventory systems (as mentioned before), external developments, and further incentivize contribution to the database.
4. contributing new parts should be trivial — the repository should have clear instructions as to how to open a PR, cli utilities to fill out information, and a clear workflow overall even for those who don’t know how to code.
5. accounts can select favorites, and their search results similarly adapt to put higher weight on semantically similar parts.
6. SKUs and onshape parts should be parametric when possible, and first party when possible. for example, rev has official onshape models for most, if not all of their SKUs. but on that note, if you want things to be parametric and relational so that it’s clear that something like shafting has different variations in length, channel can come in different hole numbers, gears can come in different sizes, motors in different gear ratios and…