Closed lobosan closed 4 years ago
@lobosan Yep yep! We have some powerful things in the works to integrate Hasura's eventing system better. Primarily, the thought process is around modelling mutations as "actions" that will fit in very naturally with a CQRS + eventing based flow.
We'll be starting discussions with the community as early as next week around some of these ideas and would love to reach out to you to set up a chat if you're interested.
Requesting interested folks to please ping me on discord or upvote this comment so that we can reach out on our discord! https://discord.gg/hasura ❤️
is it a realistic (short-term-ish) expectation for Hasura to support Apollo federation?
I am also very interested in this. We are in the process of planning our migration to GraphQL and we don't want to commit to Hasura without a clear way to extend the schema.
Adding to @coco98 's comment here about CQRS/Eventing: https://github.com/hasura/graphql-engine/issues/2329#issuecomment-498840747
Hasura style federation is also coming up very soon. Expect it in early July.
@tirumaraiselvan @coco98 Will hasura's federation be compatible with apollo version?
@lkleuver @respectTheCode @ekifox
We launched "Remote Joins", which solves the problem of federation, or distributing your GraphQL schema. Please do check it out, it's still in preview, so you'll have to try it off a docker-image. It should take you just a few minutes to try out!
Blogpost: https://blog.hasura.io/remote-joins-a-graphql-api-to-join-database-and-other-data-sources/ Github PR (with instructions on how to try it out): https://github.com/hasura/graphql-engine/pull/2395
Please do post your thoughts on our discord #preview channel: https://discord.gg/NkgqAtU ❤️
@coco98 I right understand you, Remote Joins can work only while Hasura is on top of GraphQL architecture? I want to use Apollo Federation as the main server, and Hasura like one part of "microservices".
@coco98 This is great news.
My request is that we keep terminology consistent and adopt the terminology of CQRS and DDD, where:
Therefore can you consider using the CQRS/es DDD term "Events" instead of "Actions". It is a subtle yet critical distinction. In CQRS, ES and DDD the pipelines are dealing with Events and not Actions. An Action may cause an Event but it is the Event that we are interested in. It is the Event that persists, not the Action.
Regrettably, Redux used the term Action instead of Event and this creates a slight disconnect from what is really happening and a bigger separation from what Redux emulates: CQRS/es.
Closing this issue. Feel free to re-open if there is anything to add to it 🙂
Hey guys sorry for opening this, but I just created a boilerplate showing advance usage with graphql and cqrs with EventStore and the events database. Here https://github.com/juicycleff/cqrs-graphql-boilerplate
@juicycleff how would that work with Hasura?
@coco98 I right understand you, Remote Joins can work only while Hasura is on top of GraphQL architecture? I want to use Apollo Federation as the main server, and Hasura like one part of "microservices".
We are literally trying to do this right now in our organization. It would be good to know if you guys are looking to make this a thing.
We are literally trying to do this right now in our organization. It would be good to know if you guys are looking to make this a thing.
@Manik747 Would love to chat about this. Could you please drop me a note at sandip@hasura.io?
Hi guys, last GraphQL contributors day I saw that many companies are experiencing problems with mutations and lately I've been reading about: Reactive Architecture, Command Query Responsability Segregation, Event Sourcing, Actor Model, Sagas, Eventual Consistency and Apollo Federation.
It seems to me that separating the write model from the read model and have the full history of the app in the event log has a lot of benefits for an event driven microservices architecture.
Any chance you can consider adopting these patterns?