Mirror of forum.nim-lang.org

2071 :: Synchronous threaded webserver

• incognick (orginal) [2016-02-25T23:31:15+01:00] view original

  I'm a newbie to Nim but I really like it so far coming from C++ and Python...

  I'm trying to find an example of a Nim webserver but it looks like httpserver is deprecated in favor of the asyncdispatch module. However, I'm trying to find something synchronous that handles requests in a round robin fashion so I don't have to write async code (trying to avoid async/await syntax).

  • Is this possible and/or the correct way to do this? Would you port this code over to use the net module instead?
  • Would you put nginx in front of Nim instead?

  Thanks for the help!

---

• dom96 (orginal) [2016-02-26T13:20:40+01:00] view original

  Hello incognick!

  Glad to hear that you like Nim. Might I ask, why do you want a synchronous HTTP server?

---

• incognick (orginal) [2016-02-26T16:31:30+01:00] view original

  Hey dom96 - I have a few reasons:

  • Low traffic requirements at first
  • If needed to scale, how do you scale the async server past a single system thread?
  • Prefer to write in synchronous code (easier than await/async syntax).
  • If forced to use async code, you need 3rd party libs that also support async. Example: the webserver would need a database interface. Much easier to use db_mysql than to find an async mysql db (nim-asyncmysql hasn't been updated in 10 months). This could be said for any 3rd party library. I find this same limitation in Python 3.5.

  I would prefer a coroutine solution as you could write and use synchronous modules without having to worry about async underneath.

---

• gokr (orginal) [2016-02-26T21:44:12+01:00] view original

  These are exactly the reasons I also would tend to prefer a forking server, whichever way it "forks". One wild idea is to marry Nim with Elixir/Phoenix - server side nirvana. :) You would then plug Nim in via .so libraries being called from Elixir. Humtidum...

---

• gokr (orginal) [2016-02-26T21:52:58+01:00] view original

  If one would look at that I think this article is a great place to start:

  https://spin.atomicobject.com/2015/03/16/elixir-native-interoperability-ports-vs-nifs

  Personally I don't find Nim to be such a compelling alternative for web server stuff, unless we are talking about small services running on smallish devices. For scalable stuff "in the cloud" I think Elixir and Erlang are stealing the show for the next decade.

  Do note I love Nim, but I tend to see it replace C/C++ primarily.

---

• brianrogoff (orginal) [2016-02-27T23:00:46+01:00] view original

  For scalable stuff "in the cloud" I think Elixir and Erlang are stealing the show for the next decade.

  From your lips to God's ears, certainly, but what makes you think that this might be true? If anything, I see Go being used more and more for web server stuff, and I see Nim as a mighty hunter, errr, competitor, of Go.

---

• incognick (orginal) [2016-02-28T18:43:36+01:00] view original

  Would it be possible to have a Python gevent like library in Nim? Does Nim support that sort of monkey patching?

  What I'm thinking about is being able to write synchronous web server code that doesn't block on network io.

---

• gokr (orginal) [2016-03-06T10:44:11+01:00] view original

  @brianrogoff Do note I said "I think". :) Well, first of all, Erlang is proven time and time again (WhatsApp for example, just google it). And Elixir is bringing the RoR crowd over ontop of the Erlang eco system. Yes, I know Go is also strong and I agree Nim is more directly competing with Go - but that is also why I wrote "in the cloud" - from what I know the Erlang/Elixir platform is vastly more mature in that space.

---

• andrea (orginal) [2016-03-13T20:14:06+01:00] view original

  By the way, what is exactly that is not threadsafe in the current async* modules? I see that completing a request from asynchttpserver on a different thread compiles but does not actually result in the client getting a response. I would be curious to investigate what needs to be done to allow mixing the async stuff and the threadpool module

---