MR241835: AI Catalog Effective Version Field

TL;DR

• MR241835 adds an effective version field to the AI catalog item model/GraphQL resolver
• MR has passed maintainer backend review and maintainer-level database review
• Learned about batch loading, GraphQL lazy loaders, result promises, and force promises
• Used a tool called Postgres.ai to understand query plans via explain in Postgres
• Reflected on career goals: aiming for full-stack ownership, then senior developer, and eventually staff engineer

Progress on MR241835

I’ve been working on back-end changes, and this particular one, MR241835, adds an effective version field to the AI catalog item model and GraphQL resolver. It’s a small change, but I’m happy—and honestly a bit proud—to say it has already passed maintainer back-end review as well as maintainer-level database review.

Technical learning

I learned a lot about batch loading and how GraphQL works, specifically with the GraphQL gem and GitLab’s batch loading lazy loaders. I also picked up result promises and force promises, and how to use them. The name escaped me at first, but the tool is called Postgres.ai, and it helped me work through query plans using explain in Postgres. I’ve worked with Postgres before, but I’d never really run an explain on a query or tried to understand its performance constraints. This was quite helpful.

Impact and pride

I’m proud of this work and hope it gets merged, since it represents a meaningful piece of back-end effort that also resolves a significant front-end challenge we’ve been dealing with for months around version management and version display. I’m glad I’ve had continuity on version management—implementing it on the front-end and now helping drive some fairly major optimizations on the back-end. By “major,” I don’t mean system-wide, but within a specific project vertical, where we’re rethinking how we display and select which version to show, both on the front-end and back-end. Having had a hand in both sides makes a strong case for me as a full-stack developer.

Career goals

I want to deeply understand the GitLab system and work toward owning that full stack, then broaden my understanding across different verticals—going horizontal once I have a solid vertical foundation. That breadth would let me integrate across areas and own bigger projects. My goal is to see deeply enough into a given implementation or feature request that I can identify the right people to help deliver it—people who can specialize—which in turn positions me to grow into a senior developer role. That’s what I’m aiming for first, with staff engineer or possibly management further down the line. That said, I think staff engineer is the direction I’d rather take, so I can stay grounded in the technical side.