Openapi and grpc automatically generated for Ponzu external api

[ghost]

I am thinking about getting the API more solid so that many more systems can use Ponzu.

Google have a project that can generate a ful openapi ( for test ) and grpc API. It's used for many projects and it really fills a long sort after need.

https://github.com/googleapis/gnostic

It would also allow pub sub style interaction with other systems for updates etc and so would make it very easy to integrate Ponzu into a Microservices system.
Ponzu can be what drives your front edit but also can be the opposite in that end users can edit data into Ponzu and other services would get notified !

Ponzu would then be quite an amazingly useful building block.

Also working on Ponzu would be slot more solid too since it's API is generated on top of the underlying schema.

Also because it's grpc it would make it easy to then pump any mutation across to a message queue of different varieties. This is what some teams might want for decoupling and other reasons. The point is that it's easy to use grpc middleware to do this and because it's a middleware it's not lots of new code. Hence why grpc is quite useful.

This is only a suggestion.
Love to hear feedback

[nilslice]

Hi @gedw99 ! Great to hear from you. Would you take a look at this code-gen tool I wrote, that uses Go code as the IDL: https://github.com/Fanatics/toast

You may be able to generate the API layer code from Ponzu models this way.

[ghost]

Hey Nils,

Will take a look.

I have worked out a way to do OpenAPI with Ponzu where you can run in codegen mode or reflection at runtime mode.
So you don't have to generate golang types.

I also worked out a way to make subscriptions work with it and NATS.

Will send you the doc
Will take a look at your "toast" project now !

[ghost]

Ok had a look at toast
Collector does the parsing , and plugins do the codegen.
Pretty neat and clean.
Ironic after all the time you spent on protobuf.

I still like protobuf for low level but am finding open api V3 to be pretty good sweet spot as a rest based system.

I worked out a way to use open api in a cqrs system. So you can hold the write store in certain form but have the read store in a different structure. So you don't need graphql to transform the read structure at runtime.
This makes subscriptions trivial as a result.

I like graphql but it causes a ness in the front end and I wanted to have the messy transformation on the backend where it's easier to control.