We’re excited to announce that Galaxy now supports Node.js and Python-based web applications, including frameworks like Express, Nest, Flask and Django.
This expansion provides more flexibility and scalability for your projects, all while enjoying the same reliable infrastructure that powers your Meteor apps.
Please note that both Node.js and Python hosting are currently in beta, and we are actively working to enhance and refine the service. Your feedback will be invaluable in shaping the future of these offerings.
You can find the new app types when creating a new one:
I guess I will have to start looking what my landing page should be build in (Hono and Solid are my top contenders).
That said I think we should start considering about official connectors/hooks or something where we can have user accounts from Meteor in other frameworks. So this way I can have landing page with the user logged in and make an easier transition to the app.
In general I’m hoping for some official guide in the future on nicely combining landing pages and app on Galaxy for seamless experience and Python for AI/Data Analytics stuff.
Big step and I think this is the right strategic move. Now the team needs to execute on sales, upselling existing customers, and building out an integrated dashboard to manage these varied assets. Giving Galaxy customers an easy way to manage all their apps, monitor performance, quickly chase down and fix bugs, from a single common application would deliver a tremendous competitive advantage to Galaxy. Let’s go!
Oooh, might be fun to try some things. I have a backlog of projects I’ve wanted to try out with Express/Hono and Adonis where I would have just gone with fly.io + turso or something simple. But I’m much more familiar with Galaxy.
I haven’t tried anything yet but I was wondering if it’s possible to set arbitrary Node flags? Might be fun to use --experimental-strip-types - zero-build step TypeScript hosting
That said I think we should start considering about official connectors/hooks or something where we can have user accounts from Meteor in other frameworks. So this way I can have landing page with the user logged in and make an easier transition to the app.
On a related topic Meteor-rest equivalent for meteor v3, there’s something of a draft Express middleware for Meteor auth. It’d be cool to have some auth middleware for common server-side frameworks like Express, Hono etc, maybe with the ability to run in a separate app.
(I wonder if there’s an unplugin equivalent to middleware, would be neat to have a sort of cross-platform WinterCG/WinterTC compatible middleware/plugin layer)
Congrats on the big move, hopefully this leads to more money following in and supporting Galaxy.
I’m unsure if this is a soft launch or whether you’re trying to gather feedback but maybe you could’ve gone with a little extra bang? Because it seems that not only Meteor had undergone a facelift (logo update) but also Galaxy and nobody said a word about it! This isn’t how you announce a big change like so
Anyway best of luck and I hope this plays in your favor.
It is a soft launch @harry97, we’re still collecting feedback and testing some things out. The platform is not yet ready to onboard loads of new customers at once, so doing a big launch doesn’t make sense for now :slight_smile
Regarding the rebranding of Meteor and Galaxy, we’re still applying all the new visual ID to the websites, social media and so on. We’re going to release an article about all this work and what it means soon. Just like Node and Python support on Galaxy, it doesn’t make sense to announce and make a big noise if things aren’t finished yet.
Revenue. They run a business and need to maximize income streams. That business pays for work on MeteorJS. In discussing this with the team a while back, Galaxy didn’t face any major technical hurdles to support additional runtime types. There was, of course, work to add them to the Galaxy infrastructure itself.
The growth potential for hosting Python and Node.js workloads far exceeds opportunities from pure MeteorJS deployments. It also allows them upsell opportunities to take on related workloads from existing customers. And with AI projects growing, it makes good sense to try to capture some of that business while demand is hot.
Although there is some overlap, the Galaxy and MeteorJS team are fairly independent. It’s not as if the open source team has stopped working on MeteorJS and focused instead on Galaxy.
Perhaps it is time that @fredmaiaarantes share how the teams are arranged and their commitments. Unless I’m wrong, it will be very close to how I described this.
The open source team has Capacitor and Tauri on it’s list of “Candidate Items” on the roadmap. If you’re interested in pushing it along, start a new discussion thread in Github to make a feature request. Right now, no one has done so.
After doing both Cordova and RN in the past, I only do PWA today and unless I need 3D gaming engines, complex hardware APIs or other crazy stuff … I am 100% fine with it.
I like Meteor because I can focus 100% on … mobile app development.
For really really pretentious people, PWAs can go to official apps stores.
I guess I’d have to do the research, but I suspect there are all kinds of issues in PWA with accepting app store payments, downloading assets for the first time, family sharing, notifications, running native code, etc, etc. I just doesn’t seem like a well-trodden path.
The Meteor-Cordova integration produces easily uploadable app archives for both Apple & Android. I’d happily give a Meteor-PWA-app-store integration a try if one existed, but I really don’t want to cobble it together myself.
Regards:
For really really pretentious people, PWAs can go to official apps stores.
There are many good reasons to be in the app stores. It’s nothing to do with being pretentious.
So while there are various workarounds for RN and PWA, the officially supported method of doing mobile in Meteor is still Cordova. This is a really tough sell for developers starting a new mobile app project.
You can set up Install, Build, and Start commands that will be added to a Dockerfile. This allows you to run any Python-compatible commands during container setup.
For custom requirements, you can create .sh shell scripts and use them as install/build/start commands.
