Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-12-12

Channels

#ring-swagger
<
2023-12-12
>
ambrosebs17:12:27

Hi @ikitommi, you requested a fix to a memory leak in ring-swagger a few years ago. I made a patch and have tested it in production. Here's all the context and a PR: https://github.com/metosin/ring-swagger/pull/148

ikitommi17:12:40

Hi, missed that, merged now.

ambrosebs17:12:18

I just proposed it a few minutes ago, np.

ikitommi17:12:21

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

ambrosebs17:12:27

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.

ambrosebs17:12:44

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

ambrosebs17:12:12

We have two large production systems using c-api 1.1.13

👌 1
ikitommi13:12:11

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.

ikitommi15:12:33

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

ikitommi15:12:44

(compojure-api and ring-swagger)

ikitommi15:12:27

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.

ikitommi15:12:59

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

ikitommi15:12:21

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

ikitommi15:12:02

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

❤️ 1
ambrosebs17:12:28

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

ambrosebs18:12:46

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

ambrosebs21:12:52

@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.

ikitommi13:01:24

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.

ikitommi13:01:01

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

ikitommi17:01:08

@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).

ikitommi17:01:25

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

ikitommi17:01:45

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

ambrosebs19:01:37

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).

ikitommi17:01:08

@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).