Entrepreneurs? Why not more interest

[scwewywabbit]

For sure, there are so many variations / stacks / services it mostly comes down to personal preference.

The stack running costs $0/mo for me, and allows other people to collaborate with me (I’m the only dev on the team, everyone else is a journalist or biologist). We’re running a small project, not Airbnb. But I’m about scale it up, which is why I’m moving some aspects away from Airtable (they’ll still use it, more or less as a CMS). Btw do you know of any Airtable-esque interfaces for Mongo? There’s a reason Airtable just got a huge funding round. They make stuff fast, easy, and reliable.

For Firebase/Prisma, totally agree — what I give up in control I gain back in speed and cost (and frustration, since I’m the designer/dev on the team, and we run on a $0 budget).

Interesting using Meteor as backend. Do you run a Node server with Meteor? And Meteor does the mongodb wrangling for you? Does Meteor act like an Apollo backend (since it’s the same team) and you can just run GraphQL queries? I’m gonna look into that. There are way too many tech options out there lol. I just want something low cost, cheap, fast, for a chat-like app. It’s Firebase vs. Meteor vs. Prisma right now.

Churn of tech stacks — basically I was doing Meteor/React for a while, but that was slow to dev (ugh React) and costed money to deploy Meteor server. For my latest project I’ve moved onto a completely free low-tech stack (Vue/airtable/serverless). Basically airtable so I didn’t have to build any backend interfaces lol.

[alawi]

Ah, now it makes more sense given the background and constraints you’re faced with.

Do you run a Node server with Meteor? And Meteor does the mongodb wrangling for you? Does Meteor act like an Apollo backend (since it’s the same team) and you can just run GraphQL queries?

Yes exactly, at least in that case you’ve control over a backend that you can build on, perhaps you can ask your biologist colleague a 1$ each to afford a 5$ droplet on digital ocean but yeah they won’t be able to just modify the data like a spreadsheet also if this something short-term or a POC maybe serverless make sense.

[scwewywabbit]

Ok so I’ve had trouble figuring out the difference between Apollo and Meteor. If I just run Meteor as purely a backend, isn’t it more or less like Apollo?

I remember super frustrated back in the day when Meteor would change/break a lot, which is what led me to look at other stacks. My relatively-simple Meteor apps would also be absolutely massive for some reason.

(As for cost, if I used Prisma, I’d have to deploy it on DO or Heroku anyway, so oh well)

[alawi]

Well I don’y really run Meteor that way, I’m using DDP/RPC. But one of the directions (although it’s not there yet) is to make Meteor an entry point to GraphQL using Apollo, so yeah you’ll be just using Meteor as a build tool and a server and Apollo to serve the GraphQL requests.

Meteor would change/break a lot, which is what led me to look at other stacks. My relatively-simple Meteor apps would also be absolutely massive for some reason.

I’m not sure when did you use Meteor it but I think over the last 3 years it’s been stable with new features added in backward compatible way. With regards to being massive, for me it’s mostly the client code, specially with React there is a lot of code to write and libraries are changing very quickly. I’ve not changed any backend code since I start using Meteor due to an update, but with React, every few months there is a breaking change.

[scwewywabbit]

Yeah it’s been more than 3 years… I’ll definitely give the latest Meteor a look.

Interesting about the direction of Meteor an entry point to GQL w/ Apollo. That’s exactly what the Prisma team is attempting, and I think it’s great both teams are going in that direction. Thanks for all your help!

[elie]

There are a few reasons people avoid Meteor:

It does a lot out the box which is awesome for getting started, but moving away from. The defaults isn’t always easy.
For example, if you want Postgres or Mysql it’s not going to work easily out the box. Probably just better not to touch Meteor if you want to use sql for example. This applies to a lot of items.

Mdg has mostly abandoned Meteor themselves. Probably didn’t generate the revenue for they were hoping for so they have a minimal number of developers now focused on it.

Scaling is a headache. Because everything is real time out the box you have to start worrying about scaling once you hit 50 concurrent users. The full stack reactivity Meteor provides is awesome, but a huge burden at the same time and most devs would rather do without it and add real time for the one or two items that need it and not kill their servers with everything being reactive.

As for the question of getting an mvp ready in 1 or 3 weeks, a lot of people would choose the 3 week option if it gave them a more stable platform long term. Migrating away from Meteor once your project is 6 months in is not going to be fun. If it’s a question of doing things quickly and badly or a bit slower but well, a lot of the time the second option makes more sense. Especially if a project is going to take a few years. Get things right from the beginning and don’t build up a huge amount of technical debt.

Even the Mdg focus is nowadays on apollo server and client. And not meteor publications. That should really tell its own story.

[alawi]

Yes, it’s the same criticism being said so many times in different ways. So please allow me to give you slightly different perspective on those.

@elie

Postgres or Mysql it’s not going to work easily out the box. Probably just better not to touch Meteor if you want to use sql for example

Agreed, if you don’t want MongoDB don’t use Meteor, that’s very clear.

@elie

Mdg has mostly abandoned Meteor themselves. Probably didn’t generate the revenue for they were hoping for so they have a minimal number of developers now focused on it.

Now here is an example of black and white thinking, MDG is either fully invested or not invested at all, but the truth, as stated by them several times, is somewhere in between. They’ve clearly stated that they’re committed to Meteor long-term and furthermore they’re using it internally however it’s very clear that they’re investing in Apollo and other tech and that’s good, it ensures the company is here for the long run and that the framework and community are mature enough to stand on their own feet.

@elie

Scaling is a headache. Because everything is real time out the box you have to start worrying about scaling once you hit 50 concurrent users

Scaling your own cluster is headache period. But scaling socket real-time application is more challenging, I agree. But I’ve done performance testing on Meteor and bottlenecks came from MongoDD and CPU but they were solvable. On the flip side, you do have a community who managed to scale Meteor, you’ve monitoring tools and tons of content so when you start to worry about scaling like Facebook you’re not alone. And I think you managed to scale it yourself as well, but yeah it does have extra layer of complexity (real-time sockets/fibers) to worry about.

@elie

Get things right from the beginning and don’t build up a huge amount of technical debt.

Yes, it’s desirable to have control over the entire stack, but at the same time the economical reality dictates some trade-offs. Letting go of low-level express or webpack config for quick to market and more features is a tradeoffs that make business sense.

So to summarize, the statements that it wont’ scale is simply not true but yeah you need to some effort and knowledge to scale it and if you don’t want to worry about scaling early on then go serverless or use something like Google App Engine. The other statement that’s abandoned is also not true, I mean the folks from MDG have stated several times they are committed long-term but you are right that it’s a genuine concern.

The real concern is that for people who go with express or build their own stack, underestimating the complexity, time and effort to get basic features like pub/sub, authentication going and copy the Facebook stack in the hope of having Facebook scale when they’re less then 5 people company with few months of runway.

It’s not a perfect framework and you did capture the general fear but in my opinion it’s the best of what Node has to offer and it’s the ideal framework for entrepreneurs.

[alawi]

@elie

start worrying about scaling once you hit 50 concurrent users.

Here is a screenshot of 1.5k actual concurrent users on a server, not many but surely more than 50. These are actual sessions simulated by puppeteer headless browsers. I ran out of test servers because they’re expensive to run since I’m opening too many chrome instances but the CPU/Memory usage is prepredicable.

[elie]

Awesome stuff, but I see you’re not creating any observers?

A regular Meteor app would be creating many observers the bigger it gets.

[alawi]

Ah, the app is relatively big it has newsfeed, comments, notifications all real-time on the main page, but I’ve used meteor methods as much as I can and only used reactivity when needed. When using reactivity, I made sure the observers are re-usable in fact the observers re-use is about 90% and I only subscribe when needed so that’s why you see a low number of observers.

But it’s really big app with many modules/features, it was dynamic imports that allowed us to scale the code ensuring the bundle size stays consistent while adding many features/pages.

[cloudspider]

Observers are not always directly tied to users. Fun thing is that with Meteor you could just decide what you use. Most of the platforms me (and my team) have built were using Meteor for its account, full stack reactivity and build system. Other things are mostly Meteor’s serverside doing REST requests to external API’s using the HTTP library and Meteor methods (using state managers like Redux to push them in my components). Other variations were using Meteor’s underlying publication api to fetch from an external API and published them into clientside collections.

Powerfull stuff.

[elie]

If you’re not using meteor methods or publications you’ve lost a big part of what meteor is useful for. One of its main distinguishing features.

If you’re using it this way I don’t see it being any quicker than building on regular node js / react.

If you’re using meteor accounts I think you get some observers running, but seems like from the chart it’s minimal.

[cloudspider]

I think @alawi is actually one of those people that does understand what Meteor is capable of. He’s illustrating that if the number of observers becpmes an issue, this is one of the ways to fix it.

Meteor is so much more then its DDP system. Actually exactly the thing that you mention about React and ‘just a node server’ is what I don’t get about most people. Meteor is the only platform that allows you to build a react app without any configuration and all the fancy api stuff. Next does not even come near what Meteor does. Ever tried to add apollo or scss and styled components? Good luck doing it zero config anywhere else

[serkandurusoy]

Notice the part where it says:

they last only 15 minutes at the car’s top speed

Meteor offers a lot of things but if you fixate on livedata, which provides real time updates and hard dependency on mongodb, and use that for everything, you will enjoy it a lot, but, well, your tires will dissolve and burn in 15 minutes…

You can use meteor with any client/server communication layer; ddp pub/sub, ddp methods, http rest, graphql…

You can use meteor with any database; mongodb, mysql, postgres…

You can use meteor with any ui library; angular, react, vue, blaze…

You can use and deploy meteor on any popular os; linux, osx, windows…

The only dependency is out of box pub/sub and mongodb, which, frankly, can actually be uncoupled, too, if you want because the whole publication subsystem is fully exposed as a nice api.

I have an app running within a multinational enterprise that integrates some crm data resources into a data warehouse and the app is

• a meteor app,
• has no ui,
• only exposes rest endpoints
• database is ms-sql and in fact stored procedures, not directly the tables!
• handles enormous load as it fronts crm data aggregation for many online retail ecommerce stores worldwide
• deployed on windows server

In retrospect, that app should have been called the myth buster

Please please please stop fixating on a very small and totally optional part of meteor and then arguing how bad it is for usecases that part has not been built for.

If you must, please also think about how hard it is to eat soup using a fork…

And have a nice holiday season, enjoy your well earned rest

PS: I also have apps that use the full reactive set of tools that meteor offers, those that are arguably the scalability issues and hard dependencies, and you know what, they work pretty fine for their usecases. In fact some of them are quite a bit optimized with lots of concurrent users, too. Just sayin…

[e4tless]

While the technical side of Meteor is briliant, there is almost no communication to the outside world on social media. The javascript community did not hear about Meteor’s adoptability that kept it bleeding edge even though there was a revolution going on in the Javascript landscape.

This is why Meteor has not “gone viral”. What is needed: More examples, tutorials, testimonials, whitepapers on performance and scalability, big companies talking about how much they saved in licenses, dev and testing time and a more dynamic website that shows the amazing solutions that have been built on Meteor.

Meteor has been built and maintained by BRILLIANT technologists, but desperately needs a talented Marketing leader.

[alawi]

@elie

If you’re using meteor accounts I think you get some observers running, but seems like from the chart it’s minimal.

@elie , yes we’re using accounts, pub/sub and meteor methods. But my understanding is that the Created Observer is not the total active subscriptions but the number of new observers created in a given time. And yes this is low in our case due to the low number of pub/sub used on the main page and high reuse ratio. The test was aimed to simulate real concurrent sessions without spike (1 user/5s), so yeah we’ve been driving the Bugatti slowly :-). I had another test simulating a spike and the capacity of the app is proportional to the number CPUs for the app servers and DB. But I still don’t know how you got your 50 users number, seems very low…

But even without Pub/Sub, Meteor’s convention over configuration and many other features justify the investment over express.

Happy holidays everyone !

[elie]

I got the 50 number from experience and having spoken to other Meteor developers over the years.

Pubsub is one of the main Meteor use cases. You’ve stripped it out which is why you’re seeing good performance with 1.5k users. Personally I would go with something like Apollo Server, Prisma or some other graphql based solution. Grab a boilerplate you like and there’s not too much configuration to worry about.

For accounts stuff, I’d use something like AccountsJS (a project I’ve had small involvement with). It does try and give you the out the box Meteor accounts experience. Built by a bunch of ex Meteor devs that understand the power of Meteor accounts, but no longer use it as their platform of choice.

[alawi]

@elie

You’ve stripped it out which is why you’re seeing good performance with 1.5k users.

1.5k is not even the upper limit, I couldn’t even hit the upper limit with my setup I’m still trying to scale my test servers but you can see the CPU/memory were very stable. And no I didn’t strip out anything, I just followed the best practices recommended by the community/guide.

@elie

Apollo Server, Prisma or some other graphsql based solution. Grab a boilerplate you like and there’s not too much configuration to worry about.

AccountsJS/ApolloJS are great and they’re created by ex Meteor developers trying to bring the Meteor development experience to GraphQL. But again, I’m personally not interested in chasing the latest tools, mimicking Facebook stack, or assembling many micro libraries. I’m more interested in technology that works out of the box that follows convention over configurations so I can focus on solving customer problems. The AccountJS configuration is longer than Meteor Todo List tutorial! GraphQL will never come close to RPC simplicity by design, it’s aiming for flexibility not simplicity, you can’t really beat just calling another JS function.

If a developer want to try the new trendy tools, write a lot of boilerplate code and maintain a stack of large co-operations and update their resume all power to them, these frameworks are not mutually exclusive and the larger community benefit from having different choices. But this post is about entrepreneurs and I firmly believe that Meteor provides tons of value to entrepreneurs out of the box thus freeing them to actually deliver value to their clients.

[elie]

When did Meteor without publications become a best practice?

Calling methods and putting stuff in client side collections or however else you’re doing it loses the Meteor simplicity and really takes away from the core of Meteor. It’s hardly Meteor.

[minhna]

Publications/Subscriptions is a powerful gun. But you should use it wisely or you will run out of bullets soon.