glassnet/glass.net — Glass.net: An Auto Glass Marketplace Platform
Transcript
QuickFacts
Welcome! Today we're exploring Glass dot net, a B2B marketplace that's been connecting consumers with auto glass shops for over a decade. This is a Rails four point two app with some really interesting architectural choices and a few critical issues we'll need to talk about.
PlainEnglish
So what does this platform actually do? Think of it as the backend engine for an auto glass quote service. A consumer enters their vehicle details and ZIP code, the API finds local shops with competitive pricing, and when the consumer picks a shop, Glass dot net handles the lead delivery and billing. It's a pretty elegant B2B model.
QuickFacts
Let's talk tech stack. We're looking at a Rails four point two monolith with Ruby two point five. The data layer is interesting — Postgres handles transactions while Riak, a NoSQL store, holds the massive NAGS glass catalog. Twilio powers the phone system, Postmark sends emails, and background jobs run through Que. Now, here's the first red flag: both Rails and Ruby are end-of-life. We'll come back to that.
Architecture
Here's the system architecture at thirty thousand feet. Consumers hit the Quote API with vehicle details and a ZIP code. The API queries Riak for glass options, finds shops in Postgres, runs pricing formulas, and returns quotes. When a consumer picks a shop, a webhook fires and the lead is logged. Alternatively, consumers can call through Twilio which routes them to the shop while tracking the call. Every week, the billing engine sweeps up all those leads and generates invoices.
Architecture
Let's trace a quote request step by step. The consumer sends their vehicle info and ZIP to the Quote Controller. The controller queries the NAGS Store in Riak for compatible glass types and base prices. Then it finds markets serving that ZIP code and asks each one to calculate a price using their custom pricing formula. The formula applies discounts and markups, and finally the controller returns a JSON array of shop options with prices. The whole flow is pretty snappy — most requests finish in under two hundred milliseconds.
Architecture
The data model follows a hierarchy that makes a lot of sense once you see it. An Account is like a franchise — think Papa John's corporate. Each Account has multiple Locations, which are physical shop addresses. Each Location serves one or more Markets, and a market is just a bundle of ZIP codes with custom pricing rules. When a Quote is generated, it belongs to a Market. Contact Requests and Phone Calls tie back to Locations, and those become line items on weekly Invoices. It's a clean design for multi-location businesses.
CodeQuality
Alright, let's talk code quality. Overall this codebase gets a C. The strengths are clear — there's solid test coverage for the API controllers, excellent reusable validators, and good use of Rails concerns to keep models DRY. But the weaknesses are significant. Query optimization is a problem — we've got N plus one issues in invoice generation that'll bite as the customer base grows. Error handling is sparse, and complex operations like the NAGS import are buried in giant model methods instead of service objects. It's maintainable, but it needs refactoring attention.
CodeQuality
Now we need to talk about security, because there are critical issues here. First, encryption keys are hardcoded in the model files and visible in source control. Anyone with repo access can decrypt user IDs. Second, production API credentials for Twilio and Impact Radius are committed to docker compose yaml — that's a breach waiting to happen. Third, there's a secret endpoint for call recordings that relies on obscurity instead of authentication. And finally, the framework itself is end-of-life with known vulnerabilities. These need to be fixed immediately.
Health
So what should the team tackle first? Here are the top three wins. Number one: upgrade to Rails seven and Ruby three point two. Yes, it's high effort, but it eliminates security vulnerabilities and unlocks modern gem support. Number two: move all secrets to environment variables and rotate exposed credentials. This is a four-hour fix that immediately reduces breach risk and enables compliance. Number three: add eager loading to the invoice and report queries. Change three or four lines of code and you'll see five to ten times speedup. These are your high-impact moves.
Community
Let's check the pulse of this repository. The last commit was three weeks ago, and we're seeing about two commits per month on average. There's really just one active contributor right now, with three total contributors historically. The activity signal is maintained but not active — this is a production app that's getting operational patches and bug fixes, but it's not under heavy feature development. That's totally fine for a mature product, but it does mean any major refactoring will need dedicated sprint time.
Health
So here's the verdict: this is a functional but risky codebase. The architecture is sound for a circa twenty fifteen Rails app — clear MVC separation, reasonable use of concerns, and decent test coverage for the core APIs. It's serving production traffic just fine today. But those critical security issues and the end-of-life framework are ticking time bombs. This app needs urgent attention to secrets management and a Rails upgrade roadmap before you face a breach or a compliance audit. The good news is the business logic is solid and well-understood, so the refactoring is absolutely doable.
Health
If you're diving into this codebase for the first time, here's your reading order. Start with the README for setup and architecture overview. Then check out the routes file — it's three hundred lines, but it's the best map to understand system boundaries. Next, read the Account model to understand the shop hierarchy, then the Quote Controller to see how the core API works. From there, look at Contact Request for lead logic, Invoice for billing, and the NAGS import library for the catalog system. The quote controller test file is over a thousand lines and shows you what edge cases actually matter in production.
How this was made
Lenzon read glassnet/glass.net and generated this walkthrough automatically. The narration above is the transcript of what it says.
Explain a pull request from your own repo
Point Lenzon at a repo or a pull request and get a narrated walkthrough like this one.
Try it