Disable swagger.ui in production

[brj...@gmail.com]

Hi,

I'm trying out compojure-api and have included swagger.ui in my api:

(api

  {:swagger {:ui   "/swagger-ui"

             :spec "/swagger.json"

             :data {:info {:version     "1.0.0"

                           :title       "Title"}}}}

  ...)

However, I don't want swagger to be included in my production build. What is the best way to disable swagger in production?

Best,

Brjánn Ljótsson

[Matching Socks]

Would it be fair to paraphrase the question as, how to pass a different data structure to compojure's api function depending on whether the program is running in the development environment or "in production"?  One very general technique is to wield the classpath to advantage.  Suppose for example that your program's main (i.e., entrypoint) function is in the org.draintheaquifer.asbestos namespace.  Instead of putting it under src with most of your program, you may put one version in dev/org/draintheaquifer/asbestos.clj and another version in ops/org/draintheaquifer/asbestos.clj.  Then configure Leiningen, or whatever, to include dev and src on the classpath for development (actually this may be its default setting) and ops and src in the uberjar.  An easier but more lopsided way to achieve a similar effect is to avoid calling your uberjar's aot-compiled main-class namespace from development, or in other words, let src/org/draintheaquifers/asbestos.clj configure the app for production, and instead of asbestos.clj use dev/user.clj to do the analogous thing in development.

[brj...@gmail.com]

Hi,

Thank you for the suggestion! I also got a backchannel reply that one could simply put the swagger map in a (when dev-mode? {:swagger {...}}) form. For some reason I though that wouldn't be possible because api is a macro but that actually works fine.

Thanks,

Brjánn

On Thu, 21 Feb 2019 at 01:22, Matching Socks <phill...@gmail.com> wrote:

Would it be fair to paraphrase the question as, how to pass a different data structure to compojure's api function depending on whether the program is running in the development environment or "in production"?  One very general technique is to wield the classpath to advantage.  Suppose for example that your program's main (i.e., entrypoint) function is in the org.draintheaquifer.asbestos namespace.  Instead of putting it under src with most of your program, you may put one version in dev/org/draintheaquifer/asbestos.clj and another version in ops/org/draintheaquifer/asbestos.clj.  Then configure Leiningen, or whatever, to include dev and src on the classpath for development (actually this may be its default setting) and ops and src in the uberjar.  An easier but more lopsided way to achieve a similar effect is to avoid calling your uberjar's aot-compiled main-class namespace from development, or in other words, let src/org/draintheaquifers/asbestos.clj configure the app for production, and instead of asbestos.clj use dev/user.clj to do the analogous thing in development.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Gatannah]

I'm going to buck a trend here.

Why do you want to do this? (That's rhetorical. Don't feel like you need to answer).

One of the fundamental principles behind REST is that it is discoverable. Maybe even that it's explorable.

Maybe you aren't building a REST end-point. It's totally possible that I read too much into your post.

But I'm curious about bigger-picture issues: why wouldn't you include something like swagger as part of your public API?

(Don't get me wrong: I can think of 4 different reasons off the top of my head. I'm just curious why you don't want to).