Replies: 5 comments 11 replies
-
|
We are working on a new Gateway at the moment that will have a couple more integrations for containerized setups. But no one on the team is working with Dapr so it is difficult to validate what makes sense there. If you would like to contribute something we could setup a meeting and have a discussion around dapr. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely Michael, we would very much love to contribute towards Dapr integration within your new Gateway! The Hot Chocolate Gateway provides an excellent way for us to query across domain-wide, domain services. We are currently refactoring our internal, DDD based Domain Modeling (showing below), plus Roslyn-based, CLI code-generation tooling, to generate support for GraphQL via Hot Chocolate. We hope to have mostly wrapped up very shortly (days) and would love to meet to provide a quick demo of how we are integrating Hot Chocolate into our code-generated microservices optionally over MS SQL EF or Cosmos DB projecting to Mongo DB each of which is using Hot Chocolate to include a GraphQL service per each microservice. Below is a very simple domain model we are currently using to test with. As can be seen our domain modeling tool runs as a VS Code extension, and we have a separate CLI tool that generates the model into various code artifacts as per the domain model, following an onion-style architecture. In the image below, I am highlighting the generated project and related code artifacts.
Using our Domain modeling tooling, each modeled and generated domain service further generates it's own business rules API which provides full mutation and query support over REST, gRPC and GraphQL, so as to author business rules that are executed by our Rules Engine within the domain aggregates within each microservice. We further enriched each generated domain service with it's own domain meta services API. This meta API also provides full query capabilities to reflect the domain model meta information per each domain service per each domain aggregate's associated domain commands, plus root aggregate composition of it's internal entities, value objects and enums, as well as each domain event emitted by the aggregate. This metadata includes all property details for its domain elements and is persisted within each microservice and it's API surfaced via GraphQL, REST or gRPC per each microservice, thus providing rich, meta-queryable capabilities across an entire suite of related Domain services, using the Hot Chocolate Gateway. We will utilize this meta information within our App Builder (described next) for data shaping tooling as well as for linking and subscribing domain events between aggregates across the entire set of domain services. As mentioned, we are currently working on a full-featured internal App Builder to initially compose Blazor applications but our goal is to provide the same for MAUI. Our App Builder will provide a WISWIG suite of tooling that makes it super easy to compose discrete, reusable, UI components that further compose into application component pages within grander applications. The code-generation capabilities within Strawberry Shake should work very well within the App Builder tooling to help discover and shape data for related code-generated view components, utilizing the meta data details, queried from our meta service API within each Domain service and as well within the generated applications. Our code generators will integrate within a grander Dev/Ops pipeline, each running on separate Generator Servers, triggered upon model check-in, thus changes made on a particular Domain or App UI model will automatically trigger code-generation upon check-in, and followed by build, test and deploy. Our goal is to provide these internal Low/Pro-Code capabilities such that we are able to quickly produce and support a number of enterprise quality, product offerings in a very short time frame, with a small but highly resourceful team that work directly with Business Owners to capture and model their business domain of said products and to be able to quickly deliver products that run on the Web (Blazor) and Native (MAUI) each consumers of resilient, secured and highly scalable microservices as code-generated by our internal tooling, including sub domains such as head-less, multi-tenant, e-commerce, CMS and ERP capabilities. Here is a possible high-level configuration using Dapr for service to service HTTP integrations and flow...
The only difference to how you do this with named HTTP clients (today), is the you would derive the HTPP client from Dapr (using the App Id of the external GraphQL service), I think this is just a few lines of code extra to what already exists. It is for these reasons why we would love to see Hot Chocolate Gateway fully embrace Dapr. It just makes perfect sense for our needs and likely many others as well. Please let me know how to reach you directly so that we can schedule a meeting. I am reachable via LinkedIn aka John Kears, CTO and co-founder of NextWare Group Inc. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
I send you a request to connect on linked in. |
Beta Was this translation helpful? Give feedback.
-
|
Any updates concerning this topic? Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@Vachan0 yes there is an update. It's super easy to setup. Please sign into Slack and go to this conversation thread to learn more.... If you need any further assistance, please do not hesitate to ask, I'd be more than happy to assist. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jimitndiaye , please let me know if you need me to walk you through the DAPR side of things, as I say it's not that difficult. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible for me to join the Slack channel or receive information on setting up Dapr integration? This appears to be outdated. Thanks!! |
Beta Was this translation helpful? Give feedback.
-
|
@jkears Could you provide some info about Dapr integration with GraphQL? I am really interested in integrating GraphQL into our Dapr-enabled microservices architecture. |
Beta Was this translation helpful? Give feedback.
-
|
It is very easy to setup. Are you referring using in Fusion Gateway or service config.. or both. |
Beta Was this translation helpful? Give feedback.
-
|
With Fusion Gateway, its just a few lines of code. Please let me know [email protected] and i can setup a meeting and provide a quick demo as to how this is easily configured. Glad to help the community. |
Beta Was this translation helpful? Give feedback.
-
|
@michaelstaib Br: Gergely |
Beta Was this translation helpful? Give feedback.
-
Firstly I would like to commend the team at ChilliCream on the fine work you have done on all of these wonderful products.
We have internal tooling that code-generates all of our microservices and can target repositories on either MS SQL EF or CosmosDB projecting to Mongo. We have successfully deployed both Hot Chocolate providers for EF Core and Mongo and so far all has worked out very well, so thank you so much for all that you have provided!
With our service framework we also integrate between our generated services using Dapr, which greatly simplifies the integration between services when hosted in a containerized environment.
I believe it would be super easy for you to include a Dapr option between the Hot Chocolate Gateway and downstream services, to enhance the integration of related services.
In the containerized environment where our services are hosted, Dapr provides a the service to service integration between microservices, through a simple AppID which informs Dapr routing between services. This is somewhat similar to your named Http Client approach. It would be easy to use Dapr produced HTTP clients to integrate from the Gateway to the destination services and bac, through the Gateway's side-car through Dapr routing onto the destination GraphQL service's side-car and then finally into the destination GraphQL service.
There are many advantages to this approach as pointed out on their web site, Dapr handles service discovery, message broker integration, encryption, observability, and secret management. These are all things that we would need for the Gateway and each downstream GraphQL service.
It appears this type of support could be so easily added into the Gateway integration, and if so, the enterprise benefits would be huge.
You products are well designed. Much like it seems from some other docs I've read that you are considering utilizing SignalR as the web socket communication integration between the Strawberry Shake client and GraphQL service endpoints, which if so, I think that is an excellent idea as this would allow us to utilize the SignalR SaaS offering, in order to support high demand and spikey traffic, via socket communications, indicative of microservice usage scenarios, Dapr also offers similar benefits for the same.
You have developed an amazing .Net framework for GraphQL! Thank-you!
Cheers
Beta Was this translation helpful? Give feedback.
All reactions