goloroden

wolkenkit: A JavaScript framework for building scalable APIs that use historical data

We have had a very hard time to grasp what's special with CQRS and event-sourcing, and to put it into a one-liner, but basically, I agree with you.

As said, "similar" to what Git does ;-)

Conceptually, it's still capturing the deltas, instead of storing the current state and overwriting it. Storing the history is the key ingredient here, and of course, there are differences in how to achieve this.

That's true, but on the other hand there are also successful (A)GPL open source projects … think of Linux (or MongoDB, at least for a long time).

The getting started part is only simulated, to actually get started, please see https://docs.wolkenkit.io/3.0.0/getting-started/creating-you...

But what other options than going dual-license do you have if you want to do open-source in a sustainable way? MIT does offer nothing here, unfortunately.

Thanks for your nice feedback :-)

Yes, it is already running in production, but due to NDAs, unfortunately I can't provide any details here.

Regarding the scalability most is prepared, but there are still a few things that need to be done. We would be more than happy for anyone who wants to contribute or to sponsor us. For details see https://github.com/thenativeweb/wolkenkit/issues/90

You can, as long as you open-source your commercial project's source code, according to the AGPL 3.0 license.

If you don't want to do this, you need to get an enterprise license, which does not neccessarily mean to buy one: There are other options as well (sponsored development, …).

For details, please contact us directly using hello@thenativeweb.io

PS: I'm one of the core developers of wolkenkit.

I think this is asked to see if the applicant has dreams and ideas that go beyond the status quo. Can they "think big"?

Besides, someone with big goals needs the right motivation. How much more exciting is someone whose dream is to save the world climate because he loves polar bears than someone whose dream is to lie lazily on the beach and drink cocktails?

Serious advice: Learn to live with it.

It's so much easier to say "oh yes, sounds like a nice idea" than to actually sit down and try things out. How often do you act like this on your own?

The most difficult things to deal with as a founder / creator IMHO is not to deal with criticism, but to deal with indifference. People just don't care. You can't change this.

Hence, learn to accept it.

Thanks a lot for your very nice feedback :-)

Oh :-)

Nice to meet you here :-)

Sparbuch is the German word for a savings account. The idea behind the name is as follows:

A credit institute doesn't store your current balance, but keeps a list of deposits and payouts, which can be used to recalculate the current balance (or any balance from the past).

In the same way, an event store does not store the current state, but keeps a list of events, which can be used to recalculate the current state (or any state from the past).

Yes, you are right: Many applications can work without those features that you referred to as "advanced". So, I agree that it might be a good idea to separate the docs more into the basics and advanced things.

Thanks for the suggestion :-)

(PS: I'm one of the authors of sparbuch.)

Inspired by your blog post, I've written a small tutorial on how to use OpenSSL for creating SSL certificates: https://www.thenativeweb.io/blog/2017-12-29-11-51-the-openss...

Yes, basically Flux / Redux are just implementations of the underlying pattern (and yes, that's everything but new).

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 know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.

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.

Ah, I see, thanks!

Can you elaborate, please?

Any hint on 30?

Actually, you're right. What we mean is that it's a backend for JavaScript applications, which itself uses JavaScript.

The brochure is to 2/3s an introduction to DDD, CQRS, and event-sourcing in general, not being related to a specific JavaScript framework.

The last 1/3 shows how to apply these concepts using wolkenkit, which is a specific framework.

When we created the brochure it seemed important to us to first explain the concepts in a neutral way, because we want to help people gain a better understanding of these concepts, no matter whether they are going to use wolkenkit or not.

Well, yes, there's a certain risk. We had the idea that people liked the word "wolke" (German for "cloud"). Anyway, of course, I would be very happy if you gave wolkenkit a second chance ;-)

Hey :-)

I'm one of the authors of wolkenkit, so if you have any questions, feel free to ask here :-)