Clojurians Log v2

Thanks! I'm on vacation so no problem on the timing. Thanks for the clarifications, I'll release stable versions for 2.x. I'm also playing with a porting kit for compojure-api that has the endpoint macros expand to reitit routes, if it's possible (e.g., as long as routing doesn't depend on destructuring the request).

Hi, missed that, merged now.

I just proposed it a few minutes ago, np.

Are you using c-api and ring-swagger actively? Would you be interested in contributor rights for the repos?

Yes

I am using 1.1.13, and would like to release a new ring-swagger and make c-api 1.1.14 with this fix.

Whether I do that myself or poke someone to do it, I don't mind.

This is me FWIW https://clojars.org/users/frenchy64

We have two large production systems using c-api 1.1.13

will do that next week. 2.0.0-alphas are used in real production, it has been waiting for spec to get final. In hindsight, not the best thing to wait for.

@ambrosebs you should have maintainer access now to both repositories.

(compojure-api and ring-swagger)

there doesn’t seem to be github actions to deploy the libs, we could add those so it’s also easy to release new versions.

I’ll revisit the 1. vs 2. differences, will read my notes if there is some insights on releasing 2.*.

Also, if you want to discuss about the libraries, happy to do that.

In general, have been following your work (typed, schema, malli) and trust that you skills and judgement on how the libraries should evolve.

enjoy 🙂

@ikitommi great! I can add some deploying builds and perhaps you can add an actions secret for deployment.

my understanding is that v2 was abandoned and evolved into reitit? I was only planning to maintain v1 for mostly this reason.

@ikitommi added automated deploy to ring-swagger master and compojure-api master+1.1.x. Please take a look, and if you're comfortable with it they need secrets: CLOJARS_USER and CLOJARS_TOKEN. Or LMK if you have any org secrets and I can rename.

Hi, sorry for taking so long, we had CLOJARS_DEPLOY_TOKEN which is set for both repos now. ping me if those do not work.

I’ll walk through the compojure-api codes and will write you a summary of how finished 2.0 is.

and user is metosinci. see https://github.com/metosin/jsonista/blob/master/.github/workflows/release.yml#L28-L30

@ambrosebs I checked the code and the changelogs between 1.x and 2.x. 2.x has a lot of general improvements and much improved https://www.metosin.fi/blog/muuntaja#performance (static https://github.com/weavejester/compojure/issues/148 optimization, cheshire -> jsonista and ring-middleware-format -> muuntaja). we (and many others) have used 2.x in production since the early days, it has just been waiting for spec to go beyond alpha. I don’t think spec will ever do that, so I would just update deps, verify that everything works and ship 2.0. Is reitit a successor to compojure-api? yes and no, reitit is much faster, has more features and easier to extend, but compojure-api get’s the job done and IMO is much easier to start with. So, I see both can live side-by-side. there is even a migration guide to 2.0.0 - https://github.com/metosin/compojure-api/wiki/Migration-Guide-to-2.0.0. There are other guides for 2.0.0 to. 1.x is also good, just much older and misses some intersting features (spec, async etc).

There are some features (like the coercion) where reitit had 1:1 copy of compojure-api 2.x protocols, but they have since evolved. Could think of backporting some of the things to compojure-api. Many of the common things are already as shared utility libraries: • muuntaja, spec-tools, schema-tools

also, adding malli-support to compojure-api might be interesting?