wolkenkit | source CQRS and event-sourcing framework | Microservice library

Seems like this could be the same problem described here in this Github issue.

The problem is that due to a change in the start command, we now assume that there must be a read model (which has not yet been defined, if you follow the guide).

If you simply ignore this error, and follow on, the next thing is to define the read model. Once you have done that, you can successfully run wolkenkit start.

According to the documentation of wolkenkit-eventstore, getUnpublishedEventStream is an async function, i.e. you have to call it with await. Otherwise, you don't get a stream back, but a promise (and a promise doesn't have a pipe function).

So, this line

When starting a wolkenkit application, the application is boxed in a number of Docker containers, and these containers are then started along with a few other containers that provide the infrastructure, such as databases, a message queue, ...

The reason why the application is split into several Docker containers is because wolkenkit builds upon the CQRS pattern, which suggests separating the read side of an application from the application's write side, and hence there is one container for the read side, and one for the write side (actually there are a few more, but you get the picture).

Now, since you may develop on an operating system other than Linux, the wolkenkit application may run under a different operating system than when you develop it, as within Docker it's always Linux. This means that the start command can not simply copy over the node_modules folder into the containers, as they may contain binary modules, which are then not compatible (imagine installing on Windows on the host, but running on Linux within Docker).

To avoid issues here, wolkenkit runs an npm install when starting the application inside of the containers. The problem now is that if wolkenkit did this in every single container, the start would be super slow (it's not the fastest thing on earth anyway, due to all the Docker building and starting that's happening under the hood). So wolkenkit tries to optimize this as much as possible.

One concept here is to run npm install only once, inside of a container of its own. This is the node-modules container you encountered. This container is then linked as a volume to all the containers that contain the application's code. This way you only have to run npm install once, but multiple containers can use the outcome of this command.

Since this container now contains data, but no code, it only has to be there, it doesn't actually do anything. This is why it gets created, but is not run.

I hope this makes it a little bit clearer, and I was able to answer your question :-)

PS: Please note that I am one of the core developers of wolkenkit, so take my answer with a grain of salt.

Since that code works perfectly fine (both with or without cors), I'm going to assume that you're using an old axios version. onUploadProgress was added on version 0.14.0.

If you're using an older version, you can use: progress instead of onUploadProgress, or just update to the latest version.

0.14.0 (Aug 27, 2016)

BREAKING Splitting progress event handlers into onUploadProgress and onDownloadProgress (#423)

Actually, we (at the native web, the company behind wolkenkit), ran into this problem as well.

It's actually a problem caused by one of the latest updates for Windows 10. This updated introduced a new feature called "Fast startup" which causes problems for Docker.

See this issue for more details: https://github.com/docker/compose/issues/3277

As a quick fix, you can restart Docker. As a more long term solution, you can disable the "Fast Startup" feature, see https://github.com/docker/for-win/issues/953#issuecomment-342498223

Hope this helps

PS: Please note that I am one of the core developers of wolkenkit.

Of course you can, try to install it with npm or yarn, like npm install wolkenkit

The authorization concept of wolkenkit is based on tokens.

Hence, the simplest thing to do is to have the identity provider add claims for roles, as described in ACLs for authorization and user roles (which is the article you already linked to). This works out of the box, and you do not have to provide and special logic to your wolkenkit applications except to read the token and evaluate its claims. However, this is only suited for static role models, as you'd need to change the identity provider's configuration every time a role assignment changes.

If you require a more dynamic approach, right now unfortunately you are left to your own devices. What you could do is to add a property to your aggregate that contains an array of roles (or user IDs) that you want to be able to access the aggregate. Then, in each command, you would need to check the current user against this array. But still, this means that you have predefined roles, you just could allow or restrict access to aggregate at runtime for specific roles.

If you require an even more dynamic approach, such as making up roles ad-hoc, e.g. to share data with a group that you just want to create at hand, you end up with what we call group-based authorization. Right now, there is no support for this, and AFAIK nobody has yet implemented something like that. Support for this is on the wolkenkit roadmap, but right now unfortunately there is no ETA available (maybe this is something you could contribute to wolkenkit?).

Either way, you need to make sure that your identity provider is configured correctly and wolkenkit is setup accordingly, as described in wolkenkit redirects to Auth0 even when user is logged in.

Disclaimer: I'm one of the core developers of wolkenkit, working at the native web (the company behind wolkenkit), so please take my answer with a grain of salt.

So it seems like I am unable to reproduce the error I encountered and it doesn't help that I threw away the changes in a hurry, because i wanted to finish the aggregate.

I can add the packages I want to use by adding them via yarn add or npm install, and I can use them by requiring them inside the file:

Currently there is no built-in mechanism to handle time based scheduling. But you can create a node script that gets data from a server and then uses the client SDK to send commands in order to update aggregates. You can use some kind of scheduling mechanism to run it repetitively, e.g. https://www.npmjs.com/package/node-cron