OpenAI Code-Gen Tool

[yordis]

The OpenAPI Specification (OAS) has become a widely adopted standard in the software industry for designing, building, documenting, and consuming RESTful/JSON APIs. Many businesses accompany their products and services with the OpenAPI specification. It is increasingly clear that the BEAM ecosystem needs a consistent, efficient, and comprehensive OpenAPI code-generation tool. Developing such a tool will help us achieve several key objectives:

1. Code Consistency: This tool will ensure that all generated code adheres to the same coding standards, facilitating more manageable maintenance and a more streamlined development process.
2. Increase Efficiency: It will reduce the time and effort required in creating APIs by automating a substantial portion of the coding process, allowing developers to focus more on the business logic and less on repetitive tasks.
3. Improve Quality: It will increase code quality by minimizing human error, as the code will be generated based on a predefined specification.
4. Speed: Code generators can complete in minutes which might take developers hours or days to write by hand.
5. Precision: Since code generation is automated and based on predefined specifications, the chance of human error is drastically reduced.
6. Standardization: All code produced by the generator will adhere to the same design principles and patterns, making it easier to read, debug, and maintain.

Potential follow-up Work

External Ecosystem Awareness building

While the initial goal is to create a “universally” applicable OpenAPI code-generation tool, it is also essential to consider the potential for broader adoption of Elixir/Erlang in OpenAPI documentation tools (they share code snippets of different clients as an example). They are a few solutions that we could connect with to have more exposure thru their tools and documentation.

As a working group, we can strive to make Elixir/Erlang more prominent in OpenAPI documentation tools. This will improve Elixir/Erlang's versatility and strengthen the relationship between the Erlang ecosystem and the broader OpenAPI community.

ExDoc

ExDoc is an exceptional tool that generates beautiful, easy-to-navigate documentation pages for Elixir/Erlang projects, so it could be the case to integrate OpenAPI spec into ExDoc. PoC could be done using a custom formatter and integration.

Links

• Most Popular Package OpenAPI Tool: https://openapi-generator.tech/ and https://openapi-generator.tech/docs/generators/elixir plugin
• Attempt https://github.com/beam-community/stripity-stripe/tree/main/lib/openapi
• Attempt https://github.com/elixir-tesla/tesla_openapi
• https://github.com/E-xyza/Apical
• https://github.com/open-api-spex/open_api_spex
• https://github.com/wojtekmach/openapi
• https://github.com/aj-foster/open-api-generator
• https://github.com/xerions/phoenix_swagger
• https://github.com/marmelasoft/openapi_codegen

[zachdaniel]

I love the idea, but honestly I'm not sure that this is something that our working group should be taking on. It definitely enables a certain kind of library (API client libraries), but our goal is to improve the situation for library and framework authors in general. While I wholly support the creation of the library you're talking about, I think we should probably start with smaller things like indexing the materials out there for library and framework authors, building a list of challenges that they face today, that kind of thing. I don't think that our group should be authoring libraries directly. Of course you can work on whatever you want to work on, I'm just talking about what we as a group should take on.

[yordis]

I think we should probably start with smaller things like indexing the materials out there for library and framework authors, building a list of challenges that they face today, that kind of thing

I agree. Just taking advance of async communication first, I am not proposing that we must focus on the subject. I just wanted to kick-start a conversation and gather information about it—brain storming.

---

I don't think that our group should be authoring libraries directly

I am not looking for that, for sure.

---

I intended to facilitate communication and create visibility around the topic. I hoped to have a space where we could bring issues like the one present and figure out how to support each other.

[zachdaniel]

Of course, I didn't mean to be unsupportive :) It is definitely something that would be great for the Elixir library ecosystem. Just want to make sure that, as a group, we don't try to take on the wrong things or take on too much before we've laid the groundwork. I've been a bit busy, but I appreciate all you've done keeping the group going!

[Nezteb]

For what it's worth, I'm aware of a few OpenAPI tools for Elixir:

• https://github.com/E-xyza/Apical
• https://github.com/open-api-spex/open_api_spex
• https://github.com/wojtekmach/openapi
• https://github.com/aj-foster/open-api-generator
• https://github.com/xerions/phoenix_swagger

[yordis]

Nice nice! Adding it to the description as well. Thank you so much!

[yordis]

@wojtekmach Since you work on Req and many ideas are more and less covered and talked about over there. I would like to hear your thoughts here 🙏🏻