I wrote up a quick a go example that uses runtime reflection to work with object design based off Kamil's java example: https://github.com/houqp/airflow-api-clients/blob/master/out/object/go/model_dag_run_test.go.
Code wise, it's indeed a little bit more verbose compared to deserializing/serializing a string. The tradeoff here is it's verbosity v.s. type safety. On Sat, May 30, 2020 at 2:31 AM Jarek Potiuk <jarek.pot...@polidea.com> wrote: > > Ash - QP: also - as Kamil mentioned he already generated multiple clients > in https://github.com/mik-laj/airflow-api-clients/tree/master/out/object > so if you have time , maybe you can also take a look in parallel. > > On Sat, May 30, 2020 at 11:29 AM Jarek Potiuk <jarek.pot...@polidea.com> > wrote: > > > Kamil - I believe you already have those clients generated - so i will use > > them from there. > > > > J,. > > > > On Sat, May 30, 2020 at 11:26 AM Jarek Potiuk <jarek.pot...@polidea.com> > > wrote: > > > >> OK. Indeed there seem to be quite some ambiguities and inconsistencies > >> and the knowledge we are basing our discussion on is a bit fragmented > >> and "abstract". > >> > >> Sorry for being a bit pushy but I think we are not doing enough as a > >> community to make life our users easier, and we sometimes seem to > >> proceed without fully understanding of consequences for them - > >> downplaying the importance of it. And for public API I think this is a > >> very important topic. > >> > >> I think there is an easy way to get a better understanding - simply > >> use the OpenAPI generator to generate both - clients (in a few > >> languages) and server stubs (in python) for Airflow and become the > >> "user" and try to use the client + server and see where we get from > >> there. This will haunt us for a long time if we make the wrong > >> decision here. > >> > >> For me - this is one of the most important factors on how easy it will > >> be for someone to use the API once we release it. And being able to > >> use generated clients in several languages is pretty much > >> non-negotiable requirement for the API. > >> > >> I will spend some time over the weekend trying it out and see whether > >> the problems that I pointed out are really present in our specs and if > >> they are - whether can be solved quickly - and if there are problems > >> and they need some workarounds or customizations - for me it's super > >> important that we are aware of those problems and we let the users of > >> our API know how to solve them > >> > >> I will be posting some results while I do so - I count on your help QP > >> and Ash if I see any non-obvious obstacles. > >> > >> J. > >> > > > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > > > > > -- > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/>
