Servers element should not be required about speakeasy HOT 4 OPEN

The generated enum sounds ok and the ability to set an alternative at runtime.

A mix of internal and public APIs. The URLs don't change often but they do change (order of years).

I still reckon that if it's not a mandatory field in OpenAPI then your generation shouldn't fail if missing (and it's one more obstacle in the way of people trialling your product).

from speakeasy.

Hi @davidmoten thanks for issue report.

I just wanted to follow up with some questions, if that's okay?

Generally we have taken an opinionated approach that the SDKs we generate are "batteries included" and generally work out of the box with no additional configuration needed by an end-user where possible, allowing someone to grab the SDK and just start experimenting without needing to dig into documentation too deep to figure out how to correctly configure it for a first run.

But we can definitely see the merits of a "generic" SDK for a number of different companies hosting the same API.

We do have customer's that currently do this through a "subdomain" schema ie https://{some_company}.example.com and this is supported via Templated URLs today. Would this serve your use case? This does require a default subdomain (something like api or example or test to be specified in the spec as well for that "batteries included" experience but allows end-users to change the subdomain easily.

Or are the URLs you required to be passed in vastly different and couldn't be templated? Do you have an example of what an end-user would need to specify?

If the current options don't work for you we can definitely discuss internally how to support this use case (likely some sort of configuration switch to disable the validation check on servers being defined), and get back to you on the possibility of this being added to the product.

from speakeasy.

Thanks, yeah I find the idea of templated urls to be pretty useless. We don't set server entries in any of our api definitions for the additional reason that 3 non-prod urls (dev, test, uat) and (possibly) multiple prod urls (local and cloud hosting for example) can be quite different. You need to support an override of the url anyway in the client so I don't mind if some non-existent default server url (https://url.not.yet.configured) is set by the generator because I will override it at runtime. Or of course set it empty and fail at runtime because it is empty, forcing me to configure it.

Not only that but moving my api around to different hosts after first release should just be a configuration change on a client, not require a regeneration of client code.

I'm not a serious user yet of your stuff so feel free to keep this low priority, something on the backlog.

from speakeasy.

Thanks for the info!

Generally the SDKs are generated for the "production" case and so we recommend the default server to be your production server, you can then also list all the other potential servers in the OpenAPI definition and the SDKs then generate for you typed enums etc to select from (or also provide a way to set via a string) for the additional environments as an example.

With this configuration you shouldn't need regenerate the SDK unless your production server URLs (or if you define the other environments as well) are transient and change often, if that is the case then yeah I can very much see a need to have them only provided at runtime.

Which makes me curious as to your use case for the SDKs, are these for internal usage within your own services to communicate with other internal services or SDKs you plan to release to end user of a public API?

from speakeasy.