poor readability and self-coupling in openapi

[avelino]

When I look at the moclojer code I feel that we are building it wrong, it is hard to understand (especially the openapi package).

We need to make the code simpler and more readable, the way it now increases the barrier for new contributors to get in - if I (who started the project) having trouble understanding it, imagine who is just getting here

solution

Moclojer converts the moclojer specification (yaml and edn) to openapi format and the http server is built on top of the openapi specification - that's how it works today.

The proposal would be that moclojer supports "only" the moclojer spec and who wants to use openapi we do the conversion from openapi to moclojer spec.

This way, the moclojer spec will evolve in parallel with openapi (to run on moclojer).

[matheusfrancisco]

it is an excellent idea, I have the same feeling today about it being hard to change something.

So we should do something that converts openapi format to moclojer specs.
then if someone is using moclojer and they have an openapi if they provide we will convert to moclojer specs and run the server on top of it right?

if they provide moclojer spec it will run as is.

[matheusfrancisco]

@avelino the moclojer spec is defined already? is it the yaml format we used initially or does it need to define again?

[rafaeldelboni]

I would double check if the current format of moclojer grants us a simplier conversion to the server routes, if it is the case I would remove the step to convert to openapi, plug the directly the moclojer spec into the server route.

Later create a namespace that is responsible to convert openapi -> moclojer (this could be even a lib) and integrate this back into moclojer.

[avelino]

We are following this path, the moclojer server works "only" with moclojer specification (proper) and we will have a conversion from OpenAPI to moclojer specification (openapi->moclojer).

@rafaeldelboni I would be happy with your comments on the implementation we are doing here #121