Principled code generation from OpenAPI specifications. https://guardrail.dev/
with the further added benefit of making each individual codebase more tractable for contributors.
blast_hardcheese: sounds like that could help, but i'm worried about it all being more annoying to release, and also during development when making core changes that are then used in the generators
some magicks for checking to see if the current version has already been published and skipping if so
trying to think of what the implications of the current release flow through the github UI would be though
I really like the release-notes -> publish workflow
might need to write a custom github action :\
also, all this is moot if I can't come up with a good UX for consumption from sbt/maven/gradle
also maybe a little worried about what kind of soup the git tags will look like
a plus would be extensions to guardrail core would just be able to be natively supported directly in the build tooling though
something like
<modules><module><name>http4s</name><clientClass>dev.guardrail.generators.ScalaGenerator.Http4sClientGenerator.ClientTermInterp</clientClass>... where the fqcn's are able to be specified (with sensible defaults) in the pom.xml, and so long as the codegen phase has those dependencies on the classpath everything comes together
thinking ahead, that could open modules up to the community without having to choose which build tool plugin has the features you want.
hah, for instance,
circe-java8 could be spun out without just hanging on in the core forever
this is a big change, I'll write something up and open it as an issue
first though, I'll see whether the UX is compelling.
LOL sbt is really flexible.
+val myCustomHttp4sThing = modules.http4s.client.copy(
+ newGetExtraImports={ tracingEnabled =>
+ import scala.meta._
+ dev.guardrail.Target.pure(List(q"import dev.guardrail.example"))
+ }
+)
lazy val exampleClient = (project in file("example-client"))
.settings(commonSettings)
.settings(
- Compile / guardrailTasks += ScalaClient(file("server.yaml"), pkg="example.client", framework="http4s"),
+ Compile / guardrailTasks += ScalaClient(file("server.yaml"), pkg="example.client", framework="http4s").modules(myCustomHttp4sThing, _.circe.json),
libraryDependencies ++= commonDependencies
)
damn
talk about flexibility and empowering users to work around bugs
sangria-graphql/sangria-akka-http#12 (I'm sorry for straying from REST, I hope you will forgive me)
@nickhudkins No apologies necessary! We use Sangria at work, thanks for everything you guys do!
That’s fantastic to hear! We lost Oleg (the original author) about two years ago. Extremely sad, and so we are still trying to catch up. He was incredibly brilliant and capable. I wish I knew the internals even more. We should talk! I’d love to hear your experience with it.
Oh. I'm really sorry to hear that, and certainly, I'd love to help. I've been spending some time in caliban codegen recently, and abusing Sangria by just doing rest over GraphQL 😅
So i'm working on upgrading an older service onto the latest version of guardrail. One of the generated clients in particular seems to trip up the compiler complaining about unused imports for AkkaHttpImplicits.scala and Implicits.scala, but when compared to a seemingly similar client with the same code-gen created for those file. There aren't any warnings.
I know i could just surpress the warnings, but i'm more confused as to how one client is fine, but the other triggers warnings
I think this could be due to a number of different reasons -- the types of parameters used in either client being the most likely answer, I think.
in an ideal world, we'd register features utilized as we walked the codegen and do explicit imports for distinct features.
Unfortunately, for
x-jvm-type: ..., since it gives the capability to use absolutely anything that's supported either by guardrail internally or by your own extensions, so there's no guarantee which imports would be used or not.
scalac has support for just excluding warnings for specific paths, you can see https://alexn.org/blog/2020/05/26/scala-fatal-warnings.html for a random example of what I found when googling.
scalacOptions ++= Seq(
"-Wconf:src=src_managed/.*:silent",
)
but c'est la vie
you know how I always aim to please, Shanan, I'm sorry to let you down here.
oh yeah, we've definitely just been excluding it in other systems
<arg>-Xlint:-unused,_</arg>
The -Wconf:src=... option would be preferred, as it would only exclude unused in generated sources
what guardrail may be able to do is automatically add an explicit
-Wconf:src, since we actually know exactly which directories we generated into
that would certainly improve usability
certainly. I can't look at this right now, as my time is allocated towards the modularization proposal, ramping up to the 1.x release, but if you want to test swapping that
-Xlint:-unused,_ for -Wconf:src:..., that would be a step in the right direction
oh, please disregard then, I didn't realize it was so new
it may not end up being worth it at all anyway, as a lot of warnings were removed in dotty (much to my displeasure)