Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Maybe I'm missing the advantages but I never quite understand the whole interview and job match thing where they want to find someone who did X Y Z exactly like they want to do it.... and if they didn't they're a bad fit.
Outside of some special ultra deep technical cases... that seems like a weird thing to require and just to assume they would be bad doing it your way seems off.... -
@N00bPancakes Hype Driven Development is my bet.
Fail to mention recent hype in tech and only uses old jargon and pattern equates to bad in the eyes of hype elitist. -
@bastianrob what country are you living in?
CQS
Command-Query-Separation - seperate mutators (command) from readers (query)
CQRS
Command Query Responsibility Segregation -
Nitpicky implementation of CQS. Nitpicky since it requires to have a split model system - one for commands (mutators), one for queries (readers).
ES means Event Sourcing.
God. So many abbreviations.
While I like the essence of the rant, it lacks in term of why CQRS is FAR more than a split in read | write.
Could you elaborate? -
@IntrusionCM
CQRS with ES is about separating updates and commutation of the individual operations in an eventually consistent fashion using commands and events. Commands write an event to the event store. It's first and foremost a DDD formalism, without a strong concrete domain it's not particularly useful.
Unlike CQS, CRQS+ES will utilize event denormalizers to take series of events they care about (aggregate identity relative), process the current sequence of events into an aggregation that represents the current state.
If you need fully consistent data, you expose interfaces that load from the event store based on aggregate id.
For data that doesn't need to be fully consistent, the query store exposes pulls data in its most eventually consistent state from the query store. The query store is generally read domain optimized.
The first rule of CQRS+ES, is you probably don't need CQRS+ES. And even when you do, most orgs I've seen try to use it didn't have enough understanding of their domain or processes to make it work properly. -
@IntrusionCM The post is just a rant. Not trying to preach about CQRS+ES.
My specific implementation of CQRS is that READ have its own database.
Two to be exact.
1 for Public facing website which is stored in ElasticSearch
1 for Internal business site.
Let's call these, ReadModels DB
Both have their own microservices.
---
On the write side.
- There is 1 database for EventStore.
- Command produce event which is stored in event store
- Triggers an event to message broker
- Which is then listened by every READ side services and updates their own readmodel db.
- I go further as separating READ and WRITE services physically. Giving write side less resource than read.
---
There's a public facing API gateway which exposes all READ side services.
Data team can reinterpret the data stored in EventStore.
Engineering team can replay the event and get state of data at any given time.
Business team can run through the history and detect any fraudulent activity. -
@SortOfTested I know all of that.
I was curious wether bastianrob could explain it.
Because from a database standpoint, Event Sourcing can (and you explained it very good) has no explicit transactional state.
You get the last known working state, as in replaying all events that occured and then applying them to get the end result.
This can be cumbersome. Many specialized systems utilize snapshotting to have a certain state ready and built upon snapshots a "semi transactional" state.
Event sourcing is an Audit Log / VCS - it generates tons of data.
It's one of the reasons why it's very cumbersome.
CQRS can be implemented in different ways, eg with a denormalized NoSQL backend for reads and an SQL backend for writes. Requires synchronization... Still cumbersome, but more manageable.
I found some hints in bastianrobs rant that made me question wether he fully understood the consequences.
And the abbreviation thing is just a nitpicky - it leaves a bad taste in my mouth, since abbreviations can mean a lot of different things.
TLDR: bastianrob - Event sourcing / CQRS has consequences. And I can understand why it's an very unusual choice for most projects. Unless you need auditing, it's overkill. Even when you leave ES out. -
@bastianrob missed that by a few seconds. Thanks. :)
Especially the line with "Not trying to preach" made me very happy. -
@IntrusionCM
Def don't have to tell me, I've implemented them at scale.
I do agree with his point about redux being overengineering for most applications. It's also somehow simultaneously shit engineering, one step removed from a god object, has no support for tombstoning and makes me want to punch kittens when I observe it's memory footprint. I wish people would learn rxjs and stop launching failboats.
There's a good chance from what I read that they passed because he challenged their knowledge, and that makes bad leaders defensive.
*Continues to talk about Rob like he isn't even in the room 😋 -
@IntrusionCM The core of why ES is needed is that the company needed to audit and track every changes made to the data to make sure no foul play done by Operations.
The core of why using CQRS is because the company needed the data in ElasticSearch or read side things to be eventually consistent with the SSOT.
Maybe testing my skill gets you off...
But the core of the rant is not about preaching CQRS+ES.
It's about quick to be judged to do overengineering. While those who accuse to, applies similar principle without even knowing it. -
@SortOfTested
:)
Well. I haven't used Redux, so I don't know.
Just wanted to add some content so some other guys could maybe learn something, too.
Have a cookie. ;) -
@bastianrob it was less about testing your skill set.
And as I said: I like the rant. And I definitely agree with your point about overengineering.
You wrote a very dense rant - dense in the sense of a lot of information compressed.
It was not only about testing your skill set - I wanted to decompress your rant a bit and give you a subtle hint that writing in such a dense way makes it hard to follow.
Just setting the abbreviations fixed at the beginning would have made this rant something I'd hang up on my wall (not joking).
I see many rants as an opportunity to learn stuff.
And especially in this rant _is a lot to learn_.
Thank you :) -
-
@SortOfTested hm.
Is a non sweet puff pastry with pulled porked more acceptable? It was meant to be a nice gesture. *sad* -
@bastianrob Wonderful rant! 😎
-
# Retrospective as Backend engineer
Once upon a time, I was rejected by a startup who tries to snag me from another company that I was working with.
They are looking for Senior / Supervisor level backend engineer and my profile looks like a fit for them.
So they contacted me, arranged a technical test, system design test, and interview with their lead backend engineer who also happens to be co-founder of the startup.
## The Interview
As usual, they asked me what are my contribution to previous workplace.
I answered them with achievements that I think are the best for each company that I worked with, and how to technologically achieve them.
One of it includes designing and implementing a `CQRS+ES` system in the backend.
With complete capability of what I `brag` as `Time Machine` through replaying event.
## The Rejection
And of course I was rejected by the startup, maybe specifically by the co-founder. As I asked around on the reason of rejection from an insider.
They insisted I am a guy who overengineer thing that are not needed, by doing `CQRS+ES`, and only suitable for RND, non-production stuffs.
Nobody needs that kind of `Time Machine`.
## Ironically
After switching jobs (to another company), becoming fullstack developer, learning about react and redux.
I can reflect back on this past experience and say this:
The same company that says `CQRS+ES` is an over engineering, also uses `React+Redux`.
Never did they realize the concept behind `React+Redux` is very similar to `CQRS+ES`.
- Separation of concern
- CQRS: `Command` is separated from `Query`
- Redux: Side effect / `Action` in `Thunk` separated from the presentation
- Managing State of Application
- ES: Through sequence of `Event` produced by `Command`
- Redux: Through action data produced / dispatched by `Action`
- Replayability
- ES: Through replaying `Event` into the `Applier`
- Redux: Through replay `Action` which trigger dispatch to `Reducer`
---
The same company that says `CQRS` is an over engineering also uses `ElasticSearch+MySQL`.
Never did they realize they are separating `WRITE` database into `MySQL` as their `Single Source Of Truth`, and `READ` database into `ElasticSearch` is also inline with `CQRS` principle.
## Value as Backend Engineer
It's a sad days as Backend Engineer these days. At least in the country I live in.
Seems like being a backend engineer is often under-appreciated.
Company (or people) seems to think of backend engineer is the guy who ONLY makes `CRUD` API endpoint to database.
- I've heard from Fullstack engineer who comes from React background complains about Backend engineers have it easy by only doing CRUD without having to worry about application.
- The same guy fails when given task in Backend to make a simple round-robin ticketing system.
- I've seen company who only hires Fullstack engineer with strong Frontend experience, fails to have basic understanding of how SQL Transaction and Connection Pool works.
- I've seen company Fullstack engineer relies on ORM to do super complex query instead of writing proper SQL, and prefer to translate SQL into ORM query language.
- I've seen company Fullstack engineer with strong React background brags about Uncle Bob clean code but fail to know on how to do basic dependency injection.
- I've heard company who made webapp criticize my way of handling `session` through http secure cookie. Saying it's a bad practice and better to use local storage. Despite my argument of `secure` in the cookie and ability to control cookie via backend.
rant