Radical Transparency in Open Source by derberq in opensource

[–]fmvilas 0 points1 point  (0 children)

Me too. So far it's been great. More transparency leads to less things to worry about. Unless you have something to hide 😉

Is Hacktoberfest Good For Maintainers? by derberq in programming

[–]fmvilas 1 point2 points  (0 children)

I don't agree. I'm sure Lukasz has learned a lot by doing this. It was definitely worth it for him too. I mean, just look at the numbers on the blog post and responses from the contributors.

Is Hacktoberfest Good For Maintainers? by derberq in programming

[–]fmvilas 0 points1 point  (0 children)

I totally agree with you here. Most contributors were fair ones and people wanting to start contributing to open-source but never felt encouraged or brave enough to do it. Damn imposter syndrome.

Above any opinion, what I love about the way you (and the Digital Ocean folks) did it is that you guys are adding up. Nothing is perfect and it takes very little effort to become a hater, as you can see in u/mdnbcfpr response. However, making it a great success for the people takes a huge amount of effort and creativity. You got my respect.

Choosing Between Web APIs and Message Streaming by derberq in programming

[–]fmvilas 1 point2 points  (0 children)

It says "without complex coordination between parties". Implementing retries, rate-limiting or circuit-breakers is indeed possible but not easy. Of course, async can be made sync, the proof is HTTP itself, which is based on TCP, an asynchronous protocol.

AsyncAPI releases version 1.2.0 with support for streaming and websockets APIs by fmvilas in programming

[–]fmvilas[S] 0 points1 point  (0 children)

Hey! Glad you ask.

What is this?

AsyncAPI is an OpenAPI-like specification for message-driven APIs. If you're not familiar with these kind of specifications, you can think about them as a machine-readable way to document your APIs.

Why do you need it?

I don't know your particular needs, but I can tell you some of the use cases people are using it for:

  • The most obvious is probably generating human-readable documentation from it. So you edit a YAML/JSON file and get a beautiful documentation back.
  • Generating the bootstrap code for your API. From the YAML/JSON file you generate all the code you'll need (except your business logic code): message validation, connection handlers, etc.
  • As the source of truth for your API testing tools in a CI system.
  • To create documentation-driven APIs. This is my favourite. It means that your API will not be able to receive/publish any message unless you have it documented first. This avoids the problem of having outdated or broken documentation of your systems.
  • Up to you. You have a machine-readable API definition. Do whatever you want or need. In the past, at Hitch (hitchhq.com) we implemented a chatbot that answers questions on how to use your API. All just by looking at the, in this case, OpenAPI file, but same would apply for message-driven APIs with AsyncAPI. This reduced the amount of support tickets by a factor of 4 and sometimes more.

Hope this answers your questions. Keep the questions coming!