Can anyone from the Meteor Galaxy team share the recent changes they implemented. The new version of Galaxy is extremely responsive.
Are these changes related to infrastructure changes, or codebase improvements?
If the latter, a blog post on the changes would be an interesting read!
Hey, thanks for noticing the improvements! Galaxy 2 is definitely faster now, and I’m happy to share what we’ve been working on.
The best part is that we achieved all this through code optimization rather than throwing more hardware at it. We took a careful look at how Galaxy was performing and found several ways to make it work better with what we already had. It’s still a work in progress, though, and more optimizations will come!
Here’s what we changed:
On the frontend, we tackled that frustrating delay when you click something and nothing seems to happen. We added skeleton screens and loading states throughout the app, so you immediately see that something’s happening. We also broke down our large components into smaller pieces that can load independently. This means you don’t have to wait for the entire page to load before seeing any content
The authentication system was completely rebuilt. Previously, it was running as a separate application, which meant every login had to make an extra hop. We integrated it directly into Galaxy 2, cutting out that middleman and making logins noticeably faster
For the backend, we implemented some smart caching using node-cache for our most common database calls. It’s straightforward but effective – we just store frequently requested data temporarily instead of hitting the database every time. We are also not using any Meteor publication but only Methods with Grubba’s meteor-rpc library. This gives us better caching and type safety, which makes development smoother
Push-to-deploy got a bunch of small but meaningful improvements. We streamlined various parts of the process, making it faster and more reliable
What I find really cool is that we didn’t change any infrastructure. Same servers, same containers, same resources – just better code and smarter data handling
You mentioned a blog post would be interesting, and I think that’s a great idea. These optimizations really show how you can achieve significant performance gains through thoughtful coding rather than just upgrading hardware. I’d love to dive into the technical details if people are interested in learning more about our approach
I saw it uses React Query under the hood, I guess that replaces the minimongo aspect of caching. Out of curiosity, was this or the previous galaxy ever using pub-sub?
(I started using Vue Query defensively during the awkward Meteor 2 to 3 transition period where I wanted to avoid depending on any meteor specific integrations for Vue, and I did get quite used to it, but I never did a performance comparison)