Git Product home page Git Product logo

Comments (4)

davidmoten avatar davidmoten commented on June 16, 2024 1

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.

TristanSpeakEasy avatar TristanSpeakEasy commented on June 16, 2024

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.

davidmoten avatar davidmoten commented on June 16, 2024

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.

TristanSpeakEasy avatar TristanSpeakEasy commented on June 16, 2024

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.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.