How I Migrated My App from Meteor

I agree that I made very rookie mistakes. But I didn’t mean to point fingers at a framework. I simply realized that the app I was building probably doesn’t even need the framework.

3 Likes

Deploying to AWS doesn’t have to suck, with the right CloudFormation script you could deploy entire scalable architectures with the click of a button.

The management of that architecture though, is the reason that Galaxy has a market. Some companies would rather pay a subscription than do their own DevOps, at least until they reach a certain size.

1 Like

To be honest, I don’t know anyone using VB.NET. I knew many that used VB prior (especially for macros). So your example carries a nasty prediction for the platform :slight_smile:

I don’t know anyone using VB.NET

I don’t know anyone who drives a Tesla. But I think that predicts nothing about the future of the company. :wink:

(Most of us who started off in VB graduated to VB.NET and then switched over to C#. Although VB and C# were nearly identical as far as .NET was concerned, we understood there were more jobs for C# devs, they earned higher wages and there were more code examples in C#. I have no idea what that predicts about Meteor.)

My point was just that there will always be some tools that make creating apps easy for beginners, hobbyists, and non-professionals and 1) those tools will likely evolved into something more complex, or 2) the hobbyists will eventually move on to more sophisticated frameworks. Today you can still build custom workgroup apps tools like ColdFusion, MS Access and Podio.com. My point was that maybe instead of lamenting the loss of simplicity we had back in Meteor v0.6, we just steer the students over to Sails if that’s better in every way.

Or is it?

https://kev.inburke.com/kevin/dont-use-sails-or-waterline/

@mz103,

I have the feeling there is some misinformation in your post. Meteor is great, my comments relate to the fringes.

  1. Deploying and scaling apps is not that hard, even on AWS. We use the Clusters package and it’s working great. If you are finding it hard, you should hire someone who knows what they are doing or use a hosting service (I would vote for Galaxy over the other services to support MDG - but do note that many hosting services exist and some have been around for a while)
  2. There are many courses and tutorials out there for Meteor. I doubt it’s a great cash cow for MDG.
  3. MongoDB’s model is not the same. DB’s are not the same thing as App deployments. Each App is different, so one size fits all is a challenge while a DB is a DB. Also MongoDB also makes a lot of money off commercial products and support (my guess is more than on hosting where is there is competition). Similar model to NGinx (who sells commercial technology).

Facts please!

1 Like

The point when I said “I don’t know anyone using VB.NET” is that it’s not as popular anymore. Your post said the same thing. I don’t have hard data so have to pepper it this way.

I am not lamenting simplicity, I am simply saying this is what drove adoption up. MDG is doing a great job in trying to make it suitable for all skill levels. To get into a crowded market of selling platform to companies is not easy, granted. And you can’t make that much money off startups and hobbyists.

I want to see Meteor stay, got burnt in the passed with platforms that die. And I do agree that Sails is not there yet, but the model seems to be more ‘durable’, i.e. services-based. That’s all. Time will tell.

But I am sticking around till the end.

And seriously, you don’t know anyone driving a Tesla? :slight_smile:

1 Like

i live in Tokyo. Only a few of my friends even have a car. :wink:

I agree Meteor’s ease-of-use helped it gain early traction. But let’s be honest, it was deceptively easy to get started—thanks to the insecure package, the fact that leaderboard had no routes, etc. Take Meteor accounts-ui which can save a lot of time with basic login tasks right? But once you need to customize the form design and link customer database and social profile accounts, the {{> loginButtons}} templates aren’t much real help.

Developing a reactive web app is definitely much easier than it used to be, thanks to Meteor. But it still requires quite a bit of technical mastery to develop sophisticated solutions—even with Meteor.

“Everything should be as simple as possible, but not simpler.” —Albert Einstein

4 Likes

how i learned to stop worrying and love Meteor

I hear that you are worried about Meteor’s ability to make money, but why worry? Galaxy boasts “1000s of users”. Let’s be conservative and say the real number is just 3,000. If those 3000 customers pay $50 per month, that’s about $2M per year, certainly enough to afford a few engineers.

But what if that number is closer to 5,000, and what if the average spend is more like $200 monthly? Then their revenue would be a solid $12M per year.

I’m just a tiny little small business, but my Galaxy bill was over $250 for the month of June.

invoice number 18505. Do the math!

1 Like

I didn’t understand why they changed everything from v1.2 to v1.3 (npm and React)
and now they build a new product called Apollo.

Why not keep meteor as is, (while building Apollo), improving Blaze (e.g. with something like viewmodel).
the React fans will change anyway to Apollo i guess.

What’s the big deal? Before: add a atmosphere package . After: add an NPM package or add an Atmosphere package

Why reinvent the wheel with Atmosphere? I’ve been doing Meteor dev for years, and every time I want to use some library I have to write a damn wrapper around it. Why not just let me use the NPM package directly? Now we [finally] can! Where do all those atmosphere packages come from? A lot of them are just the result of people writing wrappers around code which existed as an NPM package.

Also why not give people a choice now? You can still use Blaze if you want, or Angular, or React, you can even mix and match handlebars with Jade and React. You still have all the choice.

4 Likes

Based upon this post, a question I wonder is if it would be constructive if we could find a way to take your project and optimize it so it actually performs well in Meteor? There’s even a few simple ideas you can do with Methods rather than subscriptions to remove the real time functionality while keeping the Meteor dev speed high, and things should be nice and optimized with database configured correctly?

This might expose which functionality needs to be focused on a little bit in the future, so Meteor can quickly not only provide real time reactive apps, but rather any app.

I guess people who use npm and react would rather use Apollo than v1.3. So they could build Apollo right away, while improving v1.2.

In that case we could already big apps with Apollo and for smaller apps v1.2 is better suited.
Now i don’t know what to use 1.3, or wait for 1.4 or Apollo ?

MongoDB and Meteor’s model are exactly the same.

  • Make a great tool.
  • Provide turn-key cloud-based solutions for that tool.
  • Provide consulting for that tool.

You do realize a business model isn’t specific to what a business sells, right? It’s how you do business and make money. What you sell doesn’t matter.

And about the consulting “fail” comment; enterprises don’t want tutorials, they want solutions. As far as I can tell, Meteor is doing pretty well with it considering they’re working with Ikea and many other large companies right now.

Max, I’m curious - since we’re on a scaling thread: how is your app scaling?

Obviously if you’re spending $250 a month on Galaxy you must be doing well.

1 Like

That’s not a business model. That’s a business strategy / approach. A model is how you specifically will make money.

Strategy, approach, vision is bigger picture (e.g. make the best No-SQL DB tool out there for enterprise). The model could be: give DB away for free, charge for hosting, services, etc.

we have three apps, a client app on several containers, an admin app on two containers and a micro-service on two containers. So it all adds up!

2 Likes

Thanks @maxhodges,

Let’s say sales are about $3M – when someone says they have thousands of users, I hear “We have a few hundred paying users” :slight_smile:

50% EBITDA margin, means about $1.5M x 7 (multiples of EBITDA) = valuation of $10.5M – given you sunk over $30M, we are not there yet. That’s what concerning.

However, at least the machine continues, which is, in itself, an achievement! I am definitely comforted by your posting the bill. Thank you for being a gentleman!

Now i don’t know what to use 1.3, or wait for 1.4 or Apollo ?

Use the current version 1.3. Why wait? I’ve been running Meteor apps in production since v0.6. It’s an evolving framework, and we’ve been upgrading and dealing with the changes many times over the past couple years. You get used to it.

If you built with 1.3 today, you can upgrade to 1.4, and so on. It’s really not such a big deal. Apollo is a Technical Preview. We are eager to use it but we’re not going to build on it until the API is more officially published. We’re doing new Meteor dev with Meteor (always using the latest version) and React. When Apollo is more mature we may incrementally migrate to it.

2 Likes

you’re basically just trolling here now. Galaxy doesn’t have a non-paid tier.

Since announcing Galaxy for everyone in early March, we’ve been working with thousands of customers…

2 Likes