AsyncAPI AsyncAPI online conference, 18 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Increasing consistency and speed through code-generation by Nauman Ali | #asyncapiconf

Description

This talk was part of AsyncAPI Online Conference:
- AsyncAPI Initiative website - https://www.asyncapi.com/
- You can also watch this talk as part of full conference recording with audience questions in the LiveChat - https://youtu.be/oMSzGc5bDr4?t=6527

TALK ABSTRACT
This talk will focus on the importance of introducing code generation early into your event-driven API pipelines. Doing that will allow you to introduce consistency internally and externally, improve your speed of development and ensure conforming to the specification. Design first. Validate. Generate SDKs. Consume them to develop and test. Automate this process.

SLIDES
https://1drv.ms/p/s!AkSak6btQeDWjEYQWuu-ME5-SkiW?e=N0np3J

A

Hi everybody: this is no man all the way from Pakistan I hope all of you are staying safe and staying indoors, so I've been in the EPS space for around four years now, primarily building API to advocating about open API code generators. So a lot of experience around I'm really enjoyed working with the community because they think I agree on that.

A

So today, I'm gonna be talking about using API and how we can use and leverage SDK API to penetrate consistent, event-driven architectures, and it's been great to see the rise in popularity of async API itself and how people are really coming around to it and with this conference, I think so, starting off I think we gotta learn a lot from open API and how we come along as a community they're, so open API starting off.

A

We were having these competitions all these different steps in formats, but finally- and thankfully so we came around to one so I think one lesson 13 years to stick to one format and with all the tooling that we have seen and amazing things that people have done with the open, API I think we can all agree that their descriptions themselves are amazing. We made a big mistake of not adopting it early enough, so we saw or a few consistencies of tooling that wasn't really supporting the right versions and yeah.

A

Now that we have come to this point, we're really designing those API is first getting feedback from them and then really going on from there. So I think, there's a lot to learn and they're considering using API is type of it. We can really take those lessons in.

A

So yeah from the lesson learned there, we need to create async api's for all of our API, it's like religiously, because once you start implementing them and then maybe on the scriptures. There are so many discrepancies that starter pair, especially when your organization has more and more API, is coming along. So really, this is no-brainer, create your racing API descriptions, then what we tend to see as because a lot of the times there are versions cropping up there.

A

Breaking changes that are happening in the API is all seen those but they've developed, especially when an organization becomes large enough, and then it frustrates us as developers as to what's happening any one developer so consuming yet. So the lesson for that is design first, before getting into implementations of your API is, if you actually design it. Of course, what you can't do is really get early feedback from your stakeholders, because, honestly, changing code is painful, going into a words in creating a new words.

A

In effect, maintaining all those different versions isn't really pretty so you'd, rather seize the design itself and get feedback on it, and when you decide on the contract before you move forward this contract, will this is a KPI that you're creating would act as your single source of truth. This is where we'd be taking our lifecycle forward from having said that, we're all good with creating API descriptions.

A

Yet what happens as we see or see all these inconsistent with your faces, so some people are naming their parameters vastly K is some are naming them kami K is their same documentation.

A

That's mostly incomplete, missing descriptions missing example: values in the training doesn't make property experience, so you've got a follower style guideline now within the machine, readable description on your hand, what becomes really nice, as you can actually automate this process, and today our news for you, so just over this week and people that kind of stoplight have created a new version of spectrum, so this tool that we love to let our open, API documents now has support for it. So you should really check out words in this new version that has come along.

A

You can find the link right down there, so we do its spectral as going forward from actually validating your documents. You can let them and really link them against a predefined rule set. So it's not just about validating the schema. It's about validating. Are you following the conventions? Are you not messing descriptions and with this tool? That's? What is amazing is you can create custom rules so say in your organization's. You just want your names to be basket case.

A

You can set that create a custom rule set you wanna use only use MQTT in your organization, for you can enforce that even just like recommend that so it's not you suggest going all the way or not. You can create different levels of warnings in your style guides, depending on where your API program else and how you want to take it forward and just as you can see in the screenshot here, all you need to do is going to your CLI.

A

Let this description and you should see a list of things that you're doing wrong Tralee. You can also do this in your own visual studio code. There's an extension for that or you can make it part of your CI CD, using a kit of action, but really it's it's really powerful, so beautifully API description. It's consistent! All of the people are really following the conventions there are, but you still need to implement it and the implementation doesn't respect the contract that you made. There is really not much use of the contract.

A

There else, Genet again with a machine, readable description. You can generate code, both server-side and client-side, from 4m from it, so it really ensures that your developers are focusing on what's important, so it's actually logic for your API. It's and really building functionality, while all the redundant stuff is done by the generator, and on top of that, very importantly, your API is are built according to the contract that you decided on. So this amazing tool that folks were making KP I have created.

A

This generator allows you to generate code in DOJ's in Java for now, but we have support, add, add more templates and I think this is really the way forward to go. Now you've got a good implementation. You've got a good description, but developers were actually consuming. This API implementation are still struggling. Violence are happen. It's that documentation or incomplete documentation with an easing API and a code contract that is up to date.

A

You can actually generate documentation to so you can either generate it in markdown or HTML, don't miss out in descriptions and examples in the async API, because that is what really makes for good documentation. Even actually add these as rules in your spectral pipeline and sets descriptions or examples unnecessary. Maybe even multiple examples are necessary. That depends on how you want to go about it. Petrelli generate this documentation from a team.

A

If you want to put it somewhere into your own documentation, you can generate a markdown version or take an HTML version and publish it to github pages. It's really going to make your life easier with your documentation, baby I think a big part that we miss out on specially in organisations is.

A

You need to put this documentation for developers to discover so create a central hub where all your documentation generated from your API async API is four steps: a central hub where people can justify search and really consume your api's, and so you don't end up your developers. Gonna end up really creating duplicate, api's or doing the same thing.

A

Now a description and all the things going into whether don't really need these steps as Manuel, because you can't really assume, as they do end up making mistakes a lot but automate this process make it part of your CICE pipeline. So from your contract being written to your code being generated your documentation. Being all of this should be process, I'm always keep the design first step. First, so you're going to design it first and then ready take it from there.

A

So yeah design relent mocking we're missing out on we'll talk about, but generate your dots in code. You implement at you publish a trail coming into this whole process so that you can go back and forth on this without losing the consistency that we so badly need, and our target Tao I think async, API and the tooling has really come a long way, but there are missing tooling and considering we're doing all of this open source.

A

Mostly, you should really come in and contribute where you thank, you can add value or something that you buy for your organization. You can contribute, but we having a mocking server or a modern tool for async API would really make piling development easier, so you'd really go much faster than we can right now and we can even have contract testing the code generator that we talked about before has templates.

A

There are still messing, so you can obviously contribute to that, and even though writing descriptions in a text way is ok, but it's not really pretty so you I mean hopefully build all this so yeah. Thank you. So much I hope you can take some ideas.

A

So there are some links here to spectral: do the using I generate a and then there's a demo for what I was talking about on my github, so you can find it here and yes, I'm open to any questions or a conversations after this now. Thank you so much and a great word, Fran in team for contra city of broad.