LimeLeague: Current Status

Sep 4, 2020 | 2 minutes read

The company I founded,, has been working on a project code named LimeLeague. This product is meant to be a sports league software, and so far we have had some input from some interested parties but finding motivation is hard. One huge part of that is covid, it hit and the world stood still still. Sports leagues vanished and my motivation just dropped.

I took a break of a few months, worked on some smaller products and within the last two weeks have returned to developing it again. Taking a break was a good choice, I had been building something to scale to millions of calls a day/month like I do at my day job. This was quite simply ridiculous. Instead I embraced make something solid that can handle thousands, which is about a thousand times simpler. This doesn’t mean its not being built to be performant, but it does mean we are doing a more traditional RDBMS, MySQL. (Waffled on MySQL or Postgres). Utilizing some redis caching and trying to keep the SQL clean and the indexes hot.

The conversion is almost complete. For a history this is the 3rd major iteration of the tech stack.

Stack 1

The above was far to cutting edge with far too many moving parts. It was super hard to develop.

Stack 2

This iteration allowed no joins, treating the postgres has a KV store. Different parts of the application that would want to “join” against other parts would listen to the event queue, this proved painful to quick development.


This iteration is super traditional, far easier to development. The only two constants are dotnet core and graphql. I have not regretted either and any new project I do that needs an API will do graphql again! Switched underlying libraries, I found hot chocolate to be so much easier to use. Though the documentation is relatively poor. I switched to mysql since I didn’t want to run pgbouncer. Whenever searching is added will likely spin up a separate database for that utilizing Postgres.