Thursday, July 27, 2017
NGRX pattern in a node server
I ran into the term CQRS twice in the last while. It means Command Query Responsibility Segregation.
Essentially it means that the query, or getting data be segregated from the command, or posting data. It makes sense; the performance requirements for serving data is different from what is needed to write the data. Authentication requirements are very different as well. I suspect that many large scale implementations naturally have implemented this pattern, and an acronym formalises it.
I first read about the term in a Nestjs example. Nestjs is a server application framework using express, typescript, and a very nice dependency injection system. In an episode of Angular Air one of the guests mentioned Nestjs as a pick. My app has an Express backend, and I was getting horrified of the node callback mess without typescript, and was looking for a framework. It is quite impressive.
On another great podcast at NgHouston Brandon Roberts and Mike Ryan in response to a question whether Ngrx was useful on the server mentioned the CQRS pattern.
My dream would be to write the actions and reducers in Ngrx once and use the same code on the server. The action with payload would be the message passed between the client and the server. A Store subscription would serve the get requests, and effects would handle the post requests. The dependency injection system of Nestjs would make much of the initialization and structure of Ngrx portable.
And indeed that is the case. Getting a working store with selectors returning data, and effects posting the modifications was not that difficult.
https://github.com/derekkite/ngrx-nest is where the skeleton of the endeavor resides. Right now it isn't a working example, but more an illustration of how to do things. And there are things to fix.
Essentially it means that the query, or getting data be segregated from the command, or posting data. It makes sense; the performance requirements for serving data is different from what is needed to write the data. Authentication requirements are very different as well. I suspect that many large scale implementations naturally have implemented this pattern, and an acronym formalises it.
I first read about the term in a Nestjs example. Nestjs is a server application framework using express, typescript, and a very nice dependency injection system. In an episode of Angular Air one of the guests mentioned Nestjs as a pick. My app has an Express backend, and I was getting horrified of the node callback mess without typescript, and was looking for a framework. It is quite impressive.
On another great podcast at NgHouston Brandon Roberts and Mike Ryan in response to a question whether Ngrx was useful on the server mentioned the CQRS pattern.
My dream would be to write the actions and reducers in Ngrx once and use the same code on the server. The action with payload would be the message passed between the client and the server. A Store subscription would serve the get requests, and effects would handle the post requests. The dependency injection system of Nestjs would make much of the initialization and structure of Ngrx portable.
And indeed that is the case. Getting a working store with selectors returning data, and effects posting the modifications was not that difficult.
https://github.com/derekkite/ngrx-nest is where the skeleton of the endeavor resides. Right now it isn't a working example, but more an illustration of how to do things. And there are things to fix.
Subscribe to Posts [Atom]
