Principled code generation from OpenAPI specifications. https://guardrail.dev/
OK. I've done another pass at the
provided switchup, I think it's more stable now. The last time I tried publishing it introduced ABI incompatibilities, after a bit of back and forth I convinced SBT to use explicitly published jars when building release artifacts, which should make everything more stable overall.
Currently, we use Guardrail to generate both Server and Client part, but the generated code ends up in separate
*.server and *.client packages. Is there a way to generate only the shared data structures -- so that we could create shared functionality for them, like validators, etc -- that would be used by both Server and Client?
@sideeffffect: pretty sure the package names are coming from your configuration, not anything hard-coded in guardrail itself
we're generally very careful to not generate the same class names in clients and servers. the only thing that will get generated twice is the stuff under
definitions, but, given the same spec, they will always be the same between clients and servers
Also, if I want to have a JAR with the shared data-structures that is to be then depended upon by both Server and Client, how do I do that?
you more or less can't, at least not without some gymnastics. you could generate in models mode (as opposed to client or server) in one module, and that will give you definitions. then in the other modules you depend on that, and generate in client or server mode. but that will still generate a duplicate definitions package, so you'll have to figure out how to delete them after generation
that's not really the way most people use guardrail; the general idea is not to ship binaries based on the openapi spec at all. you ship the openapi spec, and your users generate the client themselves, using whatever tool/framework/whatever they prefer. but i do understand that some people want to ship fully-functional clients as a jar. it's just not as common, and it's a little more difficult to do properly. also not sure why you need the separate jar for the definitions, since the server will usually not use the client, and you usually don't need to ship a server. but i figure there are likely use cases i haven't thought of...
(or rather, i should say, shipping a client jar isn't difficult if you just include the definitions and client in the same module/jar)
@sideeffffect: If you're using http4s, up until 0.68.0 there was a name collision between server and client generated members, though that was resolved in https://github.com/guardrail-dev/guardrail/releases/tag/scala-http4s-v0.68.0
Hi, is there a simple fix for cases where the protocol field names contain reserved words? for example
schemas:
MacroWrapper:
type: object
required:
- macro
properties:
macro:
$ref: "#/components/schemas/ZendeskMacro"gives macro is now a reserved word; usage as an identifier is disallowed, I don't want to use the x-jvm-typeor x-scala-type extensions as a workaround because it would introduce unnecessary complexity.
If there is no fix for this yet (I'm on version 0.64) I could create an issue and for on a fix
Actually, more importantly, scalameta/scalameta@ca0de48 which will have been merged in a scalameta upgrade in guardrail, will cause
macro to be surrounded in backticks, like other reserved words
so if you can upgrade to a newer version of guardrail internally, that would be preferable.
Additionally, the new repository modularization work will mean that providing modules for Twilio-internal generators (scala-service, twilio-scala-dropwizard) will vastly reduce the amount of code that will need to be maintained. That being said, as much as I have tried to avoid using SPI, I think it would be preferable to use an SPI mapping for guardrail modules, otherwise you are relying on library eviction or pinning
One thing I've been considering is removing the
tracing boolean, as it is better served by way of composition now that mapRoutes exists in a number of frameworks. I would like to do this in a way that doesn't break Twilio, so if you know people are still using that feature directly, I can come up with a migration strategy.
1 reply
(it was possible before, though would have been more difficult due to the dependency chain)
yeah, i suggested that we should kill the submodule and start depending on the built artifacts. i'm just afraid that anything else will be a difficult maintenance burden later. unfortunately i haven't had the time to look at it myself
Yeah, that's what I had in mind as well. Good to see we're on the same page
kelnos Do you have any recollection of this? Looks like a simple typo in an uncommon framework (
scala-dropwizard): https://github.com/guardrail-dev/guardrail/pull/1331/files#diff-038ddff44db3d6599f6eaec4bece42fb97081152ff3e7eebfe554a385260a07dR96-R168
I'm trying to resolve the mass of warnings from the OpenAPI parser due to sloppy regression specifications
found that one when fixing where
default was specified
yeah that does seem to be a typo. i'm surprised the same typo isn't present in the java-DW thing tho
so interestingly, I don't think we emit defaults in the same way for java-dropwizard
when I fixed the spec, only the scala code was altered
I think despite getting to the "right" solution, I got there the wrong way, so I'm gonna take another crack at it
excited to merge that
blast_hardcheese I would like to use the basic auth for http4s feature introduced in guardrail 0.70.0. I added a basic-auth scheme in the
securitySchemes component and referenced it globally in the security section of my openapi config. However guardrail still generates the same Handler as before. I'm using the sbt plugin for the generation. Is basic auth support only available in the cli app or am I missing something?
jonasbergI I don't remember the field being added to the SBT plugin; I may be incorrect, but I believe that is required in order to get the new functionality.
guardrail-dev/sbt-guardrail#171 does the same thing for the coding and tags handler options, exposing a new set of keys and a new parameter for the auth style will need to be added. It didn't even occur to me when I was working in there yesterday, I've been trying to finalize this modularization work
Ah I see. I was reading that issue that requested the basic auth support for http4s and in there, there was an instruction how to generate a Server with auth by CLI. That's why I figured maybe this feature hasn't made it to the sbt plugin yet.
Sure, I can (try) to take care of that. I won't be able to do it today as it is already late but if there is no hurry I'm going to implement it and create a PR.
Yep -- the functionality is in the core and CLI drivers, but you're exactly right -- it didn't get all the way to the sbt plugin
I'll take care of it now and have a new release, 0.70.0.2, with that functionality shortly. It's my fault for not noticing that it wasn't finished in the first place 😉
I just started using guardrail and was not in touch with its internals
so if you want to push 0.70.0.2 soon, I agree it might be better if you do it this time 😁
ah hey: thank you for adding basic auth support 🙏
almost entirely community driven, I'm appreciative for the contribution as well 🙂
the guardrail internals are not particularly straightforward, but things are getting better I think
guardrail-dev/sbt-guardrail#172 is available for review, I'll leave it up for a few hours then merge and release