PLEASE give Meteor-CORE a build-in ORM-SUPPORT (Object-Relational Mapping)!

core
1

Hi guys,

I am a Meteor newbie trying to make my switch from Django into Meteors javascript world.
After intensivly playing around with meteor for about 3 weeks I want to give some constructive feedback:

Meteor is great and I am winning time using its frontend features,
BUT I am LOOSING time having to manually manage data-dependencies.

As data-handling is so important and a core-part of every webproject,
there really should be a METEOR CORE SOLUTION for:

  • defining models (database schemas) and their relationships (foreign-key, 1 to m, m to m) and their embedded related-data
  • putting business-logic-methods into the models
  • making ORM-style updates to the database via model-methods (model.value = x; model.save())
  • keeping a model’s data-relations in sync with each other (in mongodb style, thus embedding related data),
  • using a schema to create forms
  • automatic schema/data migration. I am just thinging: Damn, how much time will I loose manually writing my migrations?

Yes, we have SimpleSchema, Collection2, Autoform, CollectionHooks, TemplateHelpers, Astronomy and Orion,
BUT: even with combining those apps I end up with a rag rug. Leading to spaghetti-code with functions and responsibilites all over the place. And this rag rug is not really production ready.
PLUS with 3rd-party apps you never know how long they last.
PLUS the community really is loosing energy working on those different projects.

I mean: just like @jagi writes in his introduction to astronomy,
ORM stuff like this should all be included in Meteor CORE:

var post = Posts.findOne();
var authorOfPost = User.findOne();
var authorOfComment = User.findOne();
var comments
// Increase votes count by one.
post.setAuthor(user);
post.voteUp();
post.addCommentBy('comment to post', authorOfComment);

Yes, Meteor is far ahead when it comes to websockets and realtime,
BUT you should also work on the backend.

Please have a look at how Django handles this - it is PERFECT! (Django documentation | Django documentation | Django)

  • it has a perfect model-layer
  • forms can be generated by models
  • it has a perfect production-ready and automated migration system
  • it makes it really easy to switch out the database without having to change a single line of code

Anyone else here having similar toughts?

Kind regards
TheBarty

1 Like
2

Personally I’m skeptical of ORM. I’ve used them in .NET and see them as attempt at simulating simplicity by creating a lot of layers of complexity. It solves some problems, but creates new ones. It’s a trade-off of flexibility and control. Aren’t there still some issues with aggregate data in Django? Meteor is very agnostic about a lot of things. ORM frameworks are much less so.

You example leaves a lot out. Where are the validation rules and validation UI handling in your example? Where are the hooks to do a manual submit (when you want to validate something against a schema then post it to a third-party API)? I can do all that with autoform and simpleSchema very easily. Is it possible you just haven’t mastered some of these tools yet?

Django seemed far from perfect each time I’ve looked at it. Have they fixed all these issues already?

I think what you should really be asking is “How can I better structure my application code so it’s not a mess?”

We have several applications in production. We are quite happy with the organization and don’t feel they are very spaghetti-like at all.

In one case we split the app into two parts, a public-facing client and a ‘back-office’ admin app which share the same mongodb. It’s a large and complex ecommerce app with modules for order processing, payment processing, purchasing, receiving, shipping, customer support and bookkeeping. It has integrations with Stripe, PayPal, Saasu, Japan Post API, Help Scout, Mixpanel, Slack, Keen.io, Amazon S3, our own external Meteor-built micro services apps, among others. Our apps have served tens of thousands of customers and generated enough income for 8 employees. So it’s large and complex, yet we’ve kept it organized.

Maybe an ORM would be great; I’m not exactly saying it wouldn’t. It just doesn’t exist right now, but I feel what we have instead is damn powerful and flexible–and it’s also allow many of us to develop very sophisticated applications in record-time. ORM’s have issues around edge cases. They make somethings easy to do, but they make some things impossible. Doesn’t even the author of Django himself kind of hate the ORM?

http://www.mattmakai.com/what-author-django-orm-hates-about-it.html

Meanwhile I’m happy to make suggestions about code organization if you want to share any problems.

2 Likes
3

Django’s database solution’s got both its good and bad sides. It’s the one you’re used to the most, so of course it may feel like exactly suiting your needs. But let’s take a look at it. You say you don’t trust 3rd party libraries for database solutions. Where do we have NoSQL support for Django ORM? In 3rd party, independent Django-nonrel fork which is still based on dated Django 1.3 even if Django is already in 1.8 branch, with 1.9 alpha available. Can you explain me in simple words, how is that more “perfect” in your opinion?

To be honest, You remind me of myself some time ago. Coming from Doctrine ORM background, I thought exactly like you. I looked around, realized Meteor comes without ORM in the core and started to panic. Then I actually learnt doing things the Meteor way and realized it’s not as scary as it seems.

SimpleSchema + Collection2 + Autoform trio are a good tool to make things working for Meteor. They have great documentation, are highly flexible and are very easy to learn and use. They’re also consistent with each other - they’re part of the same system, just divided into few packages. Contrary to what you suggest, they’re also fully production-ready.

Meteor as an environment is a completely different beast than what you’re used to in Python world. It’s got different needs, ones that may seem out of place for devs from Ruby/Python/PHP background, but when you’ll take a look deeper, they’re pretty natural.

That’s why I don’t share your opinion, in short.

1 Like
4

Hi guys,

I am definetly a newbie so don’t take this too serious.
Meteor definetly is the future and has really great features.

And you are right: For now I just need to learn how to master the existing tools.
Aldeeds stuff is really awesome. And for now I’ll try to hook database collections up with the collection-hooks package. Meteors transform function (and the colelction-helper package) are a good step into the right direction for model helpers.

I’ll use next week to dive into how to make aldeeds schema work with relations. This manuall data-management stuff (with the help of hooks) really feels like a step backwards to me.

5

something which I find useful is to look at other meteor projects. there are a lot of open source repos. look at the code in them to see how it’s organized. you’ll find a great variety of ideas and approaches. It’s helped me decided on the style we use for our projects.

cheers and have fun!

1 Like
6

Firebase is a NoSQL store, and they just released “multi-location updates”, which is pretty much transactions for relationships. I think Meteor really needs something like this: https://www.firebase.com/blog/2015-09-24-atomic-writes-and-more.html

7

Pull requests are welcome!

1 Like
8

@maxhodges: Is there a particular well written project that you can recon to have a look at?

Right now I am especially searching for examples on how to keep embedded data in sync with simpleschema and collectionhooks for ForeignKey and ManyToMany relationships within the root object and within embedded array-objects…

Plus I’d be interested in knowing if there is a project that you guys would consider “best practise” meteor
for the current state of thirdparty apps avaibable.

Thanks a lot for your tips!

9

Take a look at https://github.com/wekan and https://github.com/TelescopeJS/Telescope

There are many other high quality open source meteor projects, but these two in particular have good patterns with collections and relationships.

10

SimpleSchema is often mentioned (which is a great package), but no one ever mentions jagi:astronomy, which is my personal favorite. Do check it out.

11

When it comes to jagi:astronomy - does it have autoform support? Or a similar tool that I can use to generate forms based on models?

1 Like
12

Astronomy, inspired by the same ORM I used for years, was a natural choice for me at first, but it just misses somethings like form generator and that’s why I go with SimpleSchema for now, waiting for Astronomy to show it’s true potential.

13

I wonder if you really might just have a mongodb data modeling issue. Have you read all the docs on it? A few that I found useful:

http://blog.mongodb.org/post/88473035333/6-rules-of-thumb-for-mongodb-schema-design-part-3

http://docs.mongodb.org/manual/tutorial/model-embedded-one-to-one-relationships-between-documents/#overview

Do you have a specific many-to-many problem you’re dealing with? Or are you just asking ‘hypothetically speaking’? if you have a real-world problem, could you perhaps share more details?

As far as an example app, take a look at this one, lots of interesting ideas in here. It seems they switched to jade recently. I first looked at it when it was still HTML

14

Hi, I would like to show my point of view on ORMs, Meteor and Astronomy. You can agree with it or not.

ORM is definitely not something that have to be built in. Meteor is modular, and that’s why some people created packages that fill that hole. Including me with Astronomy.

However, if you’re a package author and you have ever tried to mess with Meteor internals you may know that there are many areas to improve. I think this talk shouldn’t be about if Meteor should have a built in ORM system but how could MDG make it simpler to hook into some processes happening in Meteor.

As I said I see many areas to be improved. Like for example collection events. I do not mean collection hooks package but events system. There was a topic about that feature and many people agreed that it would be handy. It should be easier to hook into many processes happening in Meteor to extend its functionality.

I’ve implemented events system in Astronomy and anytime I want to extend it, it’s child’s play. I have quite a good experience in that matter and I know what I’m saying. A collection is the center of a data exchange between client and server and it should be more flexible. In my opinion it shouldn’t matter what database you’re using, the collection should always stick between your application logic and database.

I have some ideas that I’m going to propose MDG. MDG is also looking for a person that will deal with ORM. So it’s not true that they don’t want to work on it at all. They certainly have some plans but don’t share them with us :).

If it goes about Astronomy it will hit 1.0.0 version next week and from that point it will be production ready. It does not have built in forms support but I will be working on forms package after 1.0.0 release. However forms support is not something that you can’t live without. It’s easy to bind forms with a model in Astronomy. You can take a look at the example https://github.com/jagi/meteor-astronomy-examples

5 Likes
15

And one more thing about auto generated forms. I’ve used to use Doctrine and it’s a great ORM but I was never able to auto generate form that fits my needs. So I’m not a big fan of such feature. I think that it’s better to give a developer some tools and let him/her do it by him/her self.

2 Likes
16

Totally agree with jagi on forms, and I hope jagi:astronomy never has an auto form generator. It takes too much time to learn all the features and options of such a package. I’d rather just build my own form and form elements in React and re-use it among my projects.

1 Like
17

@jagi great to hear good news! :smile: Also good luck with talks with MDG.

@ffxsam it’s kinda like “I hope Meteor will never have SQL support because I prefer working with NoSQL”. Collection2 has Autoform, but it does not mean you’re stuck with using Autoform - you can do your forms any way you want instead of going with additional package.

18

Hi Jagi,

I had a look at your examples (https://github.com/jagi/meteor-astronomy-examples) and they look really good. This way we have all the code in one place.

BUT when it comes to forms it would be really really cool to have autoform-support, or something similar. Autoform with its Hooks and autogeneration is so cool and will totally work for me. And if quickform does not do it you can dig deeper into its advanced features.

+1 for a model-to-autoform feature.

19

autoform integration would be more work than it is worth. There is need to integrate reactive validation, translate mappings between multiple ways of astronomy class properties and simple schema / collection2 types and validation/custom/defaultvalue/autovalue functions etc.

There’s also a problem with maintining a plethora of (custom) field types css framework integrations for bootstrap, materialize, semantic etc, not to mention renderers like blaze/react…

The current situation with autoform is an abundance of abandoned packages among the currently published 140 of them https://atmospherejs.com/?q=autoform

Don’t get me wrong, I use autoform extensively for CRUD/admin type projects where I need to develop upwards 50 forms, but it is a love an hate relationship. Sure it is possible to use detailed afField types for detailed customization, but then what’s the point?

I think astronomy should ever have a forms framework, it must not concentrate on form generation, but rather on helpers that would simplify creating reactive forms.

3 Likes
20

@maxhodges: Thanks for those links. I definetly need to check this out.

Right now this is the issue I am struggeling with and it seems like I have to use CollectionHooks for syncing the scoopData into the scoopOrders: https://github.com/aldeed/meteor-autoform/issues/1219

I am just building same example usecases for foreign-key, and 1 to m relationships and trying to figure out the best practises for my first big meteor project.