-
Notifications
You must be signed in to change notification settings - Fork 27
Popsicle plugins #15
Comments
This would definitely be interesting to try. It is possible that different routes have different rate limits though. Also, I assume this is for a specific internal generation? Otherwise, things like rate-limiting based on a token needs to be distributed across server instances to be properly handled. Having an external consumable library make assumptions like this probably wouldn't work so well. |
@blakeembrey, the rate limit plugin was perhaps a poor example - but looking through the plugins you've made and one's that could be built, I can definitely see a need to configure the HTTP client. For example, I'm using a generated client with a plugin that retries non-idempotent requests. |
Perhaps it'd be enough to just inject your own code at the end of the file or something? That way, you could override the HTTP request method inside the generated code. |
Continuing the issue at mulesoft-labs/raml-javascript-generator#3. |
Since the client-generator is using Popsicle, it'd be very useful to be able to configure the generated Popsicle client to use plugins. Let's say that I'd like to add the popsicle-limit plugin, I'd have to add it manually after the client has been generated. While it's not too much of a hassle, it'd be ideal to be able to let a generate a new version of the client based on a change to the API's RAML schema as part of the continuous delivery process.
What do you think about the ability to point to an optional configuration file that contained things like what plugins to add, along with potential arguments for those plugins?
The text was updated successfully, but these errors were encountered: