Recently I see many posts about Astronomy. I wonder what it does better than Simple Schema. I really like the concise and meteoric way how Simple Schema works. Astronomy seems somehow unnatural to me (e.g. types are defined by strings instead of pure Javascript types). There is also AutoForm for Simple Schema, that Astronomy lacks. Why do some still prefer Astronomy over Simple Schema?
3 Likes
A few weeks ago @aldeed mentioned, that if Astronomy would exist when he started SimpleSchema he would not create it. However now he is not going to stop development of SimpleSchema and soon we will get big update for it.
As far as I understand Astronomy provides essentially all of the functionality of aldeed:collection2, matb33:collection-hooks and other features such as reactive joins. So it’s all in one package.
Does anybody can point on any comparison list between Astronomy and SimpleSchema?
1 Like
Is there already an integration for AutoForms? The last time I’ve looked on Atmosphere there was a “Astronomy to Simple Schema” converter, but I think it would be more usable if we can use AutoForms and Astronomy in combination.
Trying to revive this thread.
Any recent thoughts of why to choose one over the other?
There was a discussion about it on meteor-tuts: http://www.meteor-tuts.com/chapters/3/persistence-layer.html
go at the end of the article there is a Disqus about this
Thanks.
It’s kind of philosophical. I’m curious if there are concrete experience based decisions.
I’ve been working on an enterprise app with 1 other teammate where we opted for Astronomy. Both of us came from an OOP background. Astronomy seemed very familiar to us and that was nice, but down the road we found some annoying issues. Specifically, the way you define astronomy classes does not take advantage of ES6 classes. So we do not get any intellisense from our IDE. The inheritance feature caused us an issue with load order. The transient fields were causing subtle issues and behaving un-intuitively. The event hooks were also unintuitive ie. afterInit fires twice etc… We still like the concept of Astronomy, we just feel like it isn’t bulletproof and for our enterprise needs that was a bummer.
We’ve decided to ditch astronomy. We are currently testing the recommended approach found in the article @antoninadert linked above. My reasoning is that MeteorTuts (where the article is) is coming from highly experienced meteor devs. @diaconutheodor is one who built grapher and redis-oplog. And after reading the entire MeteorTuts guide, it all seems to come together cohesively and represents a battle-tested pattern that my colleague and I can stick to.
I’ll do my best to post back here with our findings.
4 Likes
Great input. Thanks!
As someone who has used Astronomy for some years in a big app, I would probably not go with it a second time. Yes, it is very, very convenient and succinct in the short term, but as time goes by it gets more messy having to deal with the “special” astronomy objects, containing whoknowswhat. The event system is not as reliable as I’d want, and you get tempted to add too much to class methods.
On the other hand, you have to cobble together a lot of packages to get some of the same features (like behaviours, schema checking everywhere, automagic “save” method, inheritance etc.) so there are still a lot of good things about it, which will save you lots of time. The magic can bite you sometimes though.
1 Like
Why not extend from Mongo.Collection to create dedicated wrapper subclasses for different collections a described in https://guide.meteor.com/collections.html#default-value with which, you can mimic a repository pattern and make full use of IDE features.
In fact, this got me thinking, would it perhaps make sense to extend TypeOrm http://typeorm.io/#/mongodb which already supports mongodb and can work in the browser, to support minimongo!
I don’t necessarily enjoy working with orm’s, but this would be an interesting direction to explore. Having done that, one can even go further to implement a https://nestjs.com/ style api around the whole meteor platform if that’s your thing!
1 Like
@serkandurusoy Awesome stuff TypeORM and NestJS, takes me back to Symfony2 (PHP golden days), but still inferior to Apollo GraphQL in my opinion, but still, very nice patterns.
@mattblackdev you are right about a battle tested pattern. We are now in the process of battle-testing Meteor & Apollo together and provide a migration plan. We are going to update MeteorTuts in that regard.
3 Likes
Patiently waiting for Chapter 3!
1 Like
@diaconutheodor in fact, nest does have direct support for apollo https://docs.nestjs.com/graphql/quick-start
But again, classes, dependency injection, layered patterns, orm’s and full on oop need to be your thing.
I for one have quite a dislike for the “class” and “new” keywords in javascript and tend to embrace functional patterns and composition. But for those who prefer oop style, I think typeorm and nest offer interesting choices and in fact, I have strong faith that their api’s can wrap meteor’s apis to bring such syntax and style to meteor development if one finds that promising.
I’ve been using Astronomy for two years in a production app with over 100K lines of code.
I think V2 is quite good, when the V1 had it’s quirks. The owner has been actively improving the library based on requests and ideas from users. I’m grateful.
4 Likes