Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] zio-http support #1615

Closed
wants to merge 1 commit into from
Closed

Conversation

zeal18
Copy link
Contributor

@zeal18 zeal18 commented Oct 28, 2022

So far I've defined the module, but it won't compile because it appeared that the zio-http is not published yet (local build requires building other dependencies locally as well and couldn't be verified in the CI). The plan is the following:

  • wait until zio-http finalises its api and publishes at least the first version (during this period I can start experimenting locally)
  • implement routes/endpoints/http-app generation using existing circe models generator
  • add zio-json or/and zio-schema models generation support

Issue: #1038

@zeal18 zeal18 changed the title [WIP] zio-http support #1038 [WIP] zio-http support Oct 28, 2022
@github-actions github-actions bot added the scala-support Pertains to guardrail-scala-support label Oct 28, 2022
@blast-hardcheese blast-hardcheese added the minor Bump minor version label Oct 28, 2022
@blast-hardcheese
Copy link
Member

Understood about the dependency.

I've added the minor label to this PR which bypasses the infrastructure that favors stable-only module dependencies inside guardrail.

That should help the CI get further.

@zeal18
Copy link
Contributor Author

zeal18 commented May 17, 2023

Hi @blast-hardcheese!
I found some time to continue working on this feature, but I'm struggling with the framework structure: it's too coupled. I think it's time to revise it.

The problem: the framework is too coupled and forces plugins to follow its ways. It defines generators interfaces and implements a common logic using them. The common logic prevents plugins to evolve independently, forces to them some common dependencies (for example cats and circe libraries) and complicates generating more "natural" for a particular plugin code.

Suggested solution: get rid of the common logic. Of cause the OpenAPI parsing logic should stay shared, but plugins should become as independent as possible, ideally, they could become even a separate applications

WDYT?

@blast-hardcheese
Copy link
Member

This is what I was attempting to do with the modules and SPI; I agree with the difficulties you're experiencing, the explosion of build tooling requirements is concerning though. I will try to respond with a more thorough consideration within the next week, I've been pulling a lot of long nights recently.

@blast-hardcheese
Copy link
Member

@zeal18 How do you want to proceed here, and do you still have interest in tending to this PR? Otherwise I can take a pass on getting the branch rebased, time permitting. Your choice.

@zeal18
Copy link
Contributor Author

zeal18 commented Oct 23, 2023

@zeal18 How do you want to proceed here, and do you still have interest in tending to this PR? Otherwise I can take a pass on getting the branch rebased, time permitting. Your choice.

Hi @blast-hardcheese! yes, I'm still considering continuing working on this, but I have a lack of time at the moment. I'll try to keep it moving starting from rebasing

@blast-hardcheese
Copy link
Member

@zeal18 if there's anything I can do to help please let me know.

@zeal18 zeal18 closed this Nov 26, 2023
@zeal18 zeal18 deleted the zio-http-support branch November 26, 2023 10:37
@zeal18 zeal18 restored the zio-http-support branch November 26, 2023 10:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
minor Bump minor version scala-support Pertains to guardrail-scala-support
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants