Re: Writing REST api the right way
yada exploits aleph's async model of returning futures and leverages manifold's ability to chain together futures and promises. This means you can effectively use a Java synchronous API by wrapping it in a future, or exploit an asynchronous Java API by returning a promise which is delivered in the callback. This programming model will give you a lot of options on the JVM. I'm sorry that yada is still in alpha, but I've been working hard on it recently and taking on the feedback of a number of early adopters. I hope to get to beta in a matter of weeks. HTTP is a big feature set and rushing things will lead to migration churn later on. On Thursday, 25 June 2015 21:20:05 UTC+1, Mike Grabowski wrote: Yeah, looks interesting, but unfortunately still in alpha, so I can't profit from it at this stage. But will check later! Thank you all for your responses! It's been really great source of new ideas and thoughts about API benchmarking and blocking/non-blocking approaches :) On Thursday, 25 June 2015 16:45:45 UTC+2, Dylan Butman wrote: Have you looked at yada http://yada.juxt.pro/user-guide.html ? It's an aleph compatible alternative to liberator that is swagger compatible with swagger out of the box. On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
Yeah, looks interesting, but unfortunately still in alpha, so I can't profit from it at this stage. But will check later! Thank you all for your responses! It's been really great source of new ideas and thoughts about API benchmarking and blocking/non-blocking approaches :) On Thursday, 25 June 2015 16:45:45 UTC+2, Dylan Butman wrote: Have you looked at yada http://yada.juxt.pro/user-guide.html ? It's an aleph compatible alternative to liberator that is swagger compatible with swagger out of the box. On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
Have you looked at yada http://yada.juxt.pro/user-guide.html ? It's an aleph compatible alternative to liberator that is swagger compatible with swagger out of the box. On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
Hi. About the documentation - at least ring-swagger[1] doesn't force you to use Schema as the runtime validation library, it just expects the route (and parameter) definitions to be presented to it as Schemas. So, you could validate the routes using bouncer and extract the ring-swagger schemas out of those just for documentation purposes [2,3]. Another option would be to write directly bouncer - swagger json schema mappings. Or ring-swagger could be made to support different parameter formats (native swagger, json schema, bouncer) via protocol extensions. [1] https://github.com/metosin/ring-swagger [2] https://github.com/metosin/ring-swagger/blob/master/src/ring/swagger/swagger2_schema.clj [3] https://github.com/metosin/ring-swagger/blob/master/test/ring/swagger/swagger2_test.clj tiistai 23. kesäkuuta 2015 11.33.50 UTC+2 Mike Grabowski kirjoitti: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
On Wednesday, June 24, 2015 at 4:03:39 PM UTC-4, Mike Grabowski wrote: Thanks for the reference, I've seen it before and it looks interesting, especially thanks to the failover built-in. It also greatly shows how Clojure can reduce the `Java boilerplate`. Speaking on the performance note, I am not entirely sure what's causing my REST API to be slower than `Node.js` one, I have two the same auth logic implemented in both Node/Clojure. The Node.js version is running on Heroku (London) with MongoLab hosted in (US-east-1) which can handle login in 140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on DigitalOcean with MongoHQ database hosted in the same DigitalOcean region handles the same thing in 350ms in the best case. This is really weird as the `non-database` request is 40ms faster than Node.js one. I need to investigate, but apart from that, all good so far. 350ms sounds fast enough for a low-frequency user interaction. In fact, once login is fast enough not to annoy your users, you don't *want* any more speed from it, as further speedup then only benefits blackhats trying to brute-force one of your users' accounts. So, it might be a feature, not a bug. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
On Wednesday, June 24, 2015 at 6:37:14 PM UTC-4, raould wrote: 350ms sounds fast enough for a low-frequency user interaction. In fact, once login is fast enough not to annoy your users, you don't *want* any more speed from it, as further speedup then only benefits blackhats trying to brute-force one of your users' accounts. So, it might be a feature, not a bug. Those seem like really weird statements to me. :-) a) I thought it was 250 msec as the upper abound for things feeling snappy. Tho others apparently say 100 msec or less. http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay That would apply to common actions like typing and entering. Login being slower than that isn't likely to be as much of a bother as you likely only do it infrequently, maybe as much as once a day if you're paranoid and clear cookies nightly. b) If anybody is relying on 350 msec vs. e.g. 100 msec as some grand solution to black hats brute forcing logins, I strongly suspect they are doing it very wrong. Relying on? No. But every little bit helps, and making it less economical to do bad things can have big breakpoints where an incremental additional difference turns mild badguy profits into mild losses. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
That would apply to common actions like typing and entering. Login being slower than that isn't likely to be as much of a bother as you likely only do it infrequently, maybe as much as once a day if you're paranoid and clear cookies nightly. Yeah, to me that is the sort of reasoning that leads in the long run to the kind of experiences we regularly have with the web: slow. Death of a thousand overheads of 250 msec cuts. $0.02. I know, I know, there are more important things for the engineers to fix right now, and for the forseeable future, I know! :-) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
350ms sounds fast enough for a low-frequency user interaction. In fact, once login is fast enough not to annoy your users, you don't *want* any more speed from it, as further speedup then only benefits blackhats trying to brute-force one of your users' accounts. So, it might be a feature, not a bug. Those seem like really weird statements to me. :-) a) I thought it was 250 msec as the upper abound for things feeling snappy. Tho others apparently say 100 msec or less. http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay b) If anybody is relying on 350 msec vs. e.g. 100 msec as some grand solution to black hats brute forcing logins, I strongly suspect they are doing it very wrong. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
Mike, I think you might be better off keeping as much as you can the same between the two test scenarios so that you are only comparing the differences between nodejs and clojure -- and not all kinds of other variables like co-located services/cpu-load on your various hosts, network latency differences, JVM/nodejs cache warm-up behaviors, memory pressure differences, backing store performance, etc. Consider running both apps separately on the same host (warmed up), against the same db, across the same network and so on. Also, I don't think heroku guarantees like-kind performance from launching dynos run to run given that your app may end up on different hosts with each test. Good luck with your project. Alan On Wednesday, June 24, 2015 at 1:03:39 PM UTC-7, Mike Grabowski wrote: Thanks for the reference, I've seen it before and it looks interesting, especially thanks to the failover built-in. It also greatly shows how Clojure can reduce the `Java boilerplate`. Speaking on the performance note, I am not entirely sure what's causing my REST API to be slower than `Node.js` one, I have two the same auth logic implemented in both Node/Clojure. The Node.js version is running on Heroku (London) with MongoLab hosted in (US-east-1) which can handle login in 140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on DigitalOcean with MongoHQ database hosted in the same DigitalOcean region handles the same thing in 350ms in the best case. This is really weird as the `non-database` request is 40ms faster than Node.js one. I need to investigate, but apart from that, all good so far. On Wednesday, 24 June 2015 20:49:40 UTC+2, Stuart Sierra wrote: On Tuesday, June 23, 2015, Mike Grabowski wrote: ... I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. This is pretty much unavoidable on the JVM. Java started with a multi-threaded blocking I/O model, and that's still how most Java code is written despite the availability of non-blocking I/O. The typical way to mitigate this in Java is with thread pools. The JVM is capable of handling hundreds of threads, and modern operating systems are pretty good at context-switching. For an extreme example, look at Netflix's [Hystrix], which isolates *every* library in its own thread pool, so they can guarantee timeouts and other bounded behaviors. Netflix reports that the overhead of extra threads is worth the more-predictable behavior. [Hystrix]: https://github.com/Netflix/Hystrix -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
On Tuesday, June 23, 2015, Mike Grabowski wrote: ... I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. This is pretty much unavoidable on the JVM. Java started with a multi-threaded blocking I/O model, and that's still how most Java code is written despite the availability of non-blocking I/O. The typical way to mitigate this in Java is with thread pools. The JVM is capable of handling hundreds of threads, and modern operating systems are pretty good at context-switching. For an extreme example, look at Netflix's [Hystrix], which isolates *every* library in its own thread pool, so they can guarantee timeouts and other bounded behaviors. Netflix reports that the overhead of extra threads is worth the more-predictable behavior. [Hystrix]: https://github.com/Netflix/Hystrix -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
Thanks for the reference, I've seen it before and it looks interesting, especially thanks to the failover built-in. It also greatly shows how Clojure can reduce the `Java boilerplate`. Speaking on the performance note, I am not entirely sure what's causing my REST API to be slower than `Node.js` one, I have two the same auth logic implemented in both Node/Clojure. The Node.js version is running on Heroku (London) with MongoLab hosted in (US-east-1) which can handle login in 140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on DigitalOcean with MongoHQ database hosted in the same DigitalOcean region handles the same thing in 350ms in the best case. This is really weird as the `non-database` request is 40ms faster than Node.js one. I need to investigate, but apart from that, all good so far. On Wednesday, 24 June 2015 20:49:40 UTC+2, Stuart Sierra wrote: On Tuesday, June 23, 2015, Mike Grabowski wrote: ... I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. This is pretty much unavoidable on the JVM. Java started with a multi-threaded blocking I/O model, and that's still how most Java code is written despite the availability of non-blocking I/O. The typical way to mitigate this in Java is with thread pools. The JVM is capable of handling hundreds of threads, and modern operating systems are pretty good at context-switching. For an extreme example, look at Netflix's [Hystrix], which isolates *every* library in its own thread pool, so they can guarantee timeouts and other bounded behaviors. Netflix reports that the overhead of extra threads is worth the more-predictable behavior. [Hystrix]: https://github.com/Netflix/Hystrix -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
On Tue, Jun 23, 2015 at 11:19 AM, Mike Grabowski grab...@gmail.com wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) It would be really cool if documentation could be generated from Liberator resource defs (http://clojure-liberator.github.io/). Maybe it's possible right now and I don't know about it. Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Writing REST api the right way
Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
