Fork me on GitHub

Could someone point me in the right direction with getting started with reitit and immutant? From the example it seemed like this would work.


@decim, reitit-http uses the interceptor-model and requires an interceptor executor to work. You can use pedestal or Sieppari, here’s with the latter one:

(ns user
  (:require [reitit.http :as http]
            [reitit.interceptor.sieppari :as sieppari]))

(def app
      [["/carbon" {:get {:handler (fn [_] {:status 200 :body "Carbonish 2.0"})}}]])
    {:executor sieppari/executor}))

;;-- Start Immutant web server -----------------------------
(defn start []
  "Start web server"
  (immutant.web/run #'app {:port 3333})
  (println "SERVER: STARTED!"))

(defn stop []
  "Stop web server"
  (println "SERVER: STOPPED!"))


the default web/run calls the handler synchronously, so it’s blocking despite you using manifold, core.async or some other. I have a Immutant3.0 branch somewhere, which has the :async? option like jetty does.


(it’s also 2x faster)


e.g. you should cann the app with 3 arguments: request, on-success and on-failure.


@ikitommi hmm ahh i see. i’m afraid to take on pedestal as i’m fairly new but i do have a friend that uses it. what if i went with reitit.ring instead?


yes, reitit-ring is a good option for today.


I have many PRs on the web servers & ring to get built-in support for NIO & async, might take some time to get all in. Someone should make a good abstraction over web servers, so that one could change easily between aleph, immutant, jetty etc. e.g. common way to go async, maybe websockets too. Pedestal has something like this, but it’s kinda separate island (of everything)


hmm i see. That sort of confused me. Both reitit and pedestal are used for routing so what do you get from combining the two?


i’ve actually been trying to separate the differences all night.


pedestal + reitit is just a example, mainly to show that it can be done and for those that have already invested in pedestal and would add things like swagger & coercion into their apps.


reitit-ring is for ring-users, reitit-http is bit rough (sieppari has version 0.0.0-alpha5 out), but I think it’s a stack for the future. Good thing is that the route syntax is same for all, should be possible to start with one and port to another later.


we are currently using reitit-ring in the projects (and compojure-api and others for many older ones).


I see. so say i switched over to ring/ring-handler… i would think that that would just work as is, no?


and i appreciate this…now i’m at least in the ballpark. I had no idea what I was truly looking at as far as choosing ‘http’ over ring


the app should be:

(def app


e.g. the routes is a function and needs to be called.


or with values:

(def routes
  ["/carbon" {:get home-page}])

(def app


you can nest routes in extra vectors if you like, the are flattened by the route compiler.


odd, i tried that and it threw a null pointer error on the (ring/router line)


maybe a dirty repl state? Works here ok.


hmm really not sure. i just restarted my repl and i’m experiencing the same thing. Here’s my project.clj. I assume we’re using the same versioning or similar enough.


@decim for me the main thing about pedestal is that it claims it’s production-ready, with logging already setup, some common-sense security middleware/interceptors already setup for you, and of course the interceptor chain which is a very very powerful concept. I haven’t looked closely to anything else in pure ring land though so I may be missing something.


@orestis yeah i wouldn’t mind giving pedestal a go but if i’m already having trouble with immutant it’s most likely going to be more of a set back for now


Pedestal supports immutant as a backend, even though the default template uses jetty.


I haven’t used immutant yet though.


i’ll take a look