Comment by goloroden | Hacker News Reader

Comment by goloroden | Hacker News Reader

Spoiler: I am one of the authors of a competitor product (wolkenkit), so my answer won't be perfectly objective.

IMHO Meteor is not a thing, as it builds on a wrong assumption: At the heart of Meteor is modeling your data, and it basically builds upon a CRUD approach. This is perfectly fine for very simple use cases, but it doesn't work well for more complex things, because limiting yourself to create, read, update and delete limits your expressive power dramatically.

In contrast, when we designed and developed wolkenkit, we put the verbs into the center of the development process. With wolkenkit, you model processes that describe what your application does. This way, wolkenkit is a pretty good fit if you do domain-driven design (DDD), but you do not need to do DDD to use wolkenkit.

wolkenkit gives you the option to focus on your domain expertise, and provides all the technical stuff below, such as persistence, authentication, real-time updates, and so on…

We built it based upon CQRS and event-sourcing, so you have a pretty good foundation for scaling and reporting / analyzing data. As it's only for the backend, you are free to use any UI framework you want to use, but we have a client-side SDK for JavaScript to assist you.

You can find more information at https://www.wolkenkit.io/ and in its documentation https://docs.wolkenkit.io/1.1.0/

If you just want to get started with the concepts, have a look at our 68-pages brochure on DDD, CQRS, event-sourcing and wolkenkit: https://docs.wolkenkit.io/1.1.0/downloads/brochure/

wolkenkit is available as open-source and under a commercial license. If you have any questions, feel free to contact us.

PS: At first, wolkenkit feels somewhat strange, if you are not used to CQRS, event-sourcing & co., but once you get it, I think it is a pretty good approach to developing software.

I’ve read through your pdf docs explaining wolkenkits approach to CQRS.

I think most of the value you’re describing through correctly modeling behavior to language is only important at the level with which most teams deal with data—and this isn’t necessarily the DB level. Just like our brain may use (relatively crude) bio mechanical processes to encode & recall information, yet at a higher level of abstraction relies on the flexibility of natural language, to codify and transmit meaning between idea storage systems (people), I think a similar process is at place with programming. Let the low level stuff stay low level and optimize for performance/throughout and not meaning, then in the higher order aspects of code make sure the abstractions that are most used by teams map data to constructs which humans use to communicate meaning.

I think this approach can be found in any framework, including meteor through effective abstractions, as nearly all frameworks give you the necessary mechanisms to map data. I think the issue with ineffective language systems is mostly the same reason people hate poetry. Most people have a difficult time adequately mapping ideas to language, because it is extremely difficult to do it correctly to the satisfaction of others.

I think you might need to give Meteor a second look, if only to learn a few things from it. It has nothing to do with (and does much more than) CRUD.

I know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.

Well - if you mean that MongoDB has a CRUD-like API, and Meteor uses MongoDB, yes, but other than that I do not see the connection. Can you explain?

E.g., if you have a look at Meteor's documenation, especially the part on collections (https://guide.meteor.com/collections.html), it is all about the classical MongoDB-like functions to access data which perfectly represent CRUD. It also describes hooks on INSERT/UPDATE/DELETE (https://guide.meteor.com/collections.html#hooks).

This pretty much shows how Meteor sees data: It's a "thing" that can be created, edited, deleted. That's it. It does not live on its own.

E.g., when you design a shopping cart, you can create a shopping cart, you can update it (which means adding items to it, or removing items from it, or changing the numbers of items in it, …), and you can finally delete it (when the user submits their order, or when they cancel their shopping tour).

What you can NOT do is to access your data using the verbs that are relevant for your domain:

- Put an item to the shopping cart - Increase the count of a specific item - Decrease the count of a specific item - Remove an item from the shopping cart - Discard the shopping card

For the domain "shopping", all these actions are relevant, and if you have to map them to CRUD actions, you lose semantics. What's even worse, update and delete are destructive actions, so you don't have any historical data. Of course you can implement all this, but you have to do it on your own.

wolkenkit, in contrast, uses event-sourcing, which works more like Git: Changes are collected, and you can replay them (either all to get the current state, or some of them for arbitrary analytics).

That's IMHO a major difference on whether you are using a CRUD-like foundation, or another approach.

We have also blogged about this: https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co... and https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co...

I'm not super familiar with DDD but I do like the ideas behind it - in some cases I think I am doing something similar to it.

However - isn't that essentially creating another layer on top of MongoDB? It looks like this could be implemented as a library for Meteor.

I'm only saying that to clarify that I do not think it's Meteor CRUD versus this. I think of Meteor more as a boilerplate than an application framework.

Reply on news.ycombinator.com