Graphql suggestion

[ghost]

This is very cool and powerful approach for ponzu. Gotta sort out some time to try this.

But I wanted to also suggest that the live queries architecture opens up the ability to put graphql on top.
There are sort of 2 aspects to this:

1. The Client can subscribe via Graphql to changes for a query.
2. Ponzu "Microservices" can subscribe to each other. Say you have a Ordering service, but its dependent on a Products service. See this for a great example of this:

• Code: https://github.com/tinrab/spidey
• Docs: https://outcrawl.com/go-graphql-gateway-microservices/
  Now that example is using grpc for each Service and mapping GraphQL on top. Ponzu with live queries can do the same.

The natural use case is that you can build isolated ponzu Microservices using good old ponzu and have reusable ponzu Microservices for your many projects by building a layer on top to unite those ponzu Microservices.
Also it will make building front end applications easier because you can use graphql for the front end, which is becoming pervasive inthe community.

Gqlgen ( https://github.com/99designs/gqlgen ) seems to be thundering along as the choice graphql library for golang.
For Ponzu, the interesting bit is that gqlgen has a plugin architecture ( 99designs/gqlgen#354). This would mean that you don't have to describe everything in your gqlgen config. You can see the Use case and why its great for Ponzu here ( 99designs/gqlgen#228 ).

Now because ponzu is a CMS it might be very possible to use the parser / plugin only by hooking into the introspection data that ponzu can provide to map in the Graphql resolvers.
A web GUI for configuring the way graphql resolvers map to ponzu Microservices can then add the extra data needed in addition to the introspection data provided from each ponzu Microservice. A web GUI also feels very appropriate to the ethos of Ponzu, so developers can quickly see whats going on, and adapt the system easily.

But I hope I wrote it well enough to get the idea across.

One thing that i have noticed with Graphql, is that its sometimes much easier to reason about system its GraphQL is used with a CQRS based architecture underneath it.

• Mutations are sent to a handler that creates events that go into a Event Store, from which the Services subscribe.
• Queries are sent to the Graphql Handler and the rest is pretty obvious.

Ponzu Live seems to sort of add the ability to do the Event Sourcing, but not yet the CQRS formal aspects.
Here is a pretty good example of this: https://github.com/yehohanan7/flux

• Its not using NATS or KAFKA to handle the subscriptions, but just HTTP.

A good example of this is a "CreateProduct" Mutation / Command. When you add the product to the DB, you will also want to update a Bleve search system. So you want to edit two databases ( the BoltDB one & the bleve boltDB one). Whats important is that the Products DB is both read and write and so maybe i should not be calling this a CQRS system, but instead just a Event Sourcing system.
Other examples might require 10 or 20 Services to interact in some way.
All this leads to huge reusability when Ponzu Services can be isolated and made to work together using Ponzu Live, and the top layer using Graphql.

One last note that is interesting, is that each Service can expose itself over Graphql also perhaps.
This is kind of nice because its what they call a Fractal Self symmetry architecture. This is a fancy word, but its an almighty concept.
https://en.wikipedia.org/wiki/Self-similarity.
Say that your Project is dependent on a third party system running on another domain. For example, a chat system. If it exposes its API as GraphQL its going to be easy to consume into Ponzu because you already talk GraphQL and can easily talk to all your own Ponzu Services over GraphQL.
The third party chat service may itslef talk over Graphql to all its own Services.
The above example is a good way to illustrate Fractal Self Similarity in programming.
I have heard it also called "Turtles all the way down".

Lastly, why bringup Fractals ?
Fractals are everywhere in Nature ( see: https://letuongan.wordpress.com/2013/04/16/the-geometry-of-nature/ ) Its how everything works. The most interesting aspect for how this relates to code is that all natural systems achieve this by using generative design architecture. In coding that is called Choreography ( the opposite is called Orchestration).
What is the difference ?
"This means that a choreography differs from an orchestration with respect to where the logic that controls the interactions between the services involved should reside." (ref: https://stackoverflow.com/questions/4127241/orchestration-vs-choreography)

Ponzu live is allowing Choreography and hence GraphQL.

In Summary, and sorry about going a bit deep on this but its worth understanding the big picture of Why and How..

1. Ponzu live allows ponzu services to do Choreography
2. Choreography opens the door to building decouples services that react to each other
3. GraphQL formalises this using a formal SDL ( Software Defines Language) so that your own and third party services can interact.

Hoping this was not a waste of time to write... I really like how Ponzu works for many reason.
Live is going to a huge thing for Ponzu and i wanted to add my 2 cents to showing how it can be extended to be even more useful and reusable ( i.e Fractal Self Similar :) ).

[ghost]

@nilslice I have rewritten this issue but not finished it yet.

I realised there was more juice in it in terms of how useful it can be.
I need to experiment with it and some code and come back with a better description of the architecture and its benefits.

Ping me if you want to see it unfinished for discussion..