我应该用 Erlang 重写 webapp 前端吗？
我有一个 Rails web 应用程序 [部署在 Heroku 上]，它使用 Heroku 的 rake:cron 功能重复对其他站点进行一系列 HTTP 调用。 目前的情况并不理想； rake:cron 进程在单线程中执行，这意味着 HTTP 调用是顺序进行的； 这意味着对同一站点的调用之间存在很长的时间[通常为 2 分钟]。
我想并行执行这个过程，并将调用之间的时间减少到 10 秒。 看过 Kevin Smith 的《Erlang 实践》后，我对使用 Erlang 作为替代后端的想法很感兴趣。 我想弄清楚[鉴于Damien Katz的评论]，我是否应该 a) 用 Erlang 重新编写整个 web 应用程序、前端和全部，或者 b) 保持一个拆分结构，使用 Rails 前端/Erlang 后端。
我喜欢在项目中使用 100% Erlang 堆栈的想法； 我需要使用某种 Erlang Web 框架 [Nitrogen？ 埃利网？]； 我担心他们还不够成熟，我会花时间和他们一起陷入项目的网络部分。
有人有意见吗？ 谢谢。
I have a Rails webapp [deployed on Heroku] which makes a series of HTTP calls to other sites on a repeated basis, using Heroku's rake:cron feature. The current situation isn't ideal; the rake:cron process is executed in a single thread, which means HTTP calls are made sequentially; which means in turn that there's a long time between calls to the same site [typically 2 mins].
I'd like to execute this process in parallel, and reduce the time between calls to 10 secs. Having seen Kevin Smith's 'Erlang in Practice' I'm sold on the idea of using Erlang as a replacement backend. What I'm trying to figure out [given Damien Katz's comments], is whether I should a) re-write the entire webapp in Erlang, front end and all or b) maintain a split structure, with a Rails frontend / Erlang backend.
I like the idea of using a 100% Erlang stack for the project; I'll need to use some kind of Erlang web framework [Nitrogen ? Erlyweb ?]; I'm concerned they're not mature enough and I'll spend my time bogged down on the web part of the project with them.
Anyone any views ? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
（HTTP 后端调用之间的两分钟间隔）对访问者的实际影响是什么？
如果没有太大区别，我会说这听起来像是过早的优化，并且您现在最好跳过 Erlang。
What's the actual impact on your visitors (of the two-minute interval between HTTP backend calls)?
If there isn't much of a difference, I'd say this sounds like premature optimization and that you'd be much better off skipping Erlang for now.
前两张海报几乎涵盖了您问题的哲学方面。 因此，我将回答您问题中框架成熟度/陷入困境的部分。
如果您决定出于某种原因确实想要在 erlang 中重写 web 应用程序，那么我不会太担心框架会减慢您的速度。 erlyweb 和 Nitroyer 的功能都已经足够完善，您可以很快地使用它们。 我用氮气开发了一个相当复杂的敏捷项目管理应用程序，发现它非常直观，而且并不缺乏我需要的功能。 晚上几个小时和几周后，我就启动并运行了一个可以运行的应用程序。
至于使用哪一个取决于您想要构建的应用程序的类型。
Nitrogen 的目标是极其动态的 Web 应用程序。 大部分页面是使用 JavaScript 呈现的，并且是高度事件驱动的。
ErlyWeb 更适合以内容为主要焦点的网站，而不是富客户端类型的应用程序。 它使用 MVC 风格的架构。
无论你做出什么决定，祝你好运。
The two previous posters have pretty much covered they philosophical aspects of your question. So I'll answer the framework maturity/getting bogged down part of your question.
In the event that you decide you do want to rewrite the webapp in erlang for whatever reason then I wouldn't be too concerned about the framework slowing you down. Both erlyweb and nitrogen are already feature complete enough that you can work pretty quickly with them. I've developed a fairly complex agile project management app in nitrogen and found it to be quite intuitive and not really lacking in features that I needed. A few hours in the evenings and a few weeks later and I had a working app up and running.
As to which one to use that depends on the type of app you want to build.
Nitrogen's target is extremely dyamic web applications. Most of the page is rendered using javascript and it is highly event driven.
ErlyWeb is more suited to a site where the content is the primary focus less so than a rich client type of application. It uses the MVC style of architecure.
Good luck on whatever you decide.
这取决于。 你了解多少 Erlang？ 您已经编写了多少代码？
您有多少项目经验？ 这是为了工作还是为了娱乐？
从头开始重写项目通常会导致灾难，尤其是当您尝试这样做时
一路学习一门新语言。 在我看来，如果您已经精通两种语言，您就不会问这个问题，在这种情况下，如果这是一个工作项目，我建议您坚持使用 Ruby。
我不同意上面的海报，即更改语言是一种过早的优化，如果有必要。
改变语言是一件大事。 不能在最后一刻才完成。
但是，由于您概述的原因，我可能根本不会更改语言。
如果您除了性能之外没有任何其他原因进行切换，您可能应该只是
查看 Ruby 中的多线程或其他一些优化。
It depends. How much Erlang do you know? How much code have you already written?
How much project experience do you have? Is this for work or for fun?
Rewriting projects from scratch is often a recipe for disaster, especially if you are trying
to learn a new language along the way. It seems to me like you would not be asking this question if you were already fluent in both languages, in which case I would recommend that you just stick to Ruby if it's a work project.
I disagree with the above poster that changing the language is a premature optimization, if it is necessary.
Changing the language is a big deal. It can't be done at the last minute.
However, I would probably not change the language at all for the reason you outlined.
If you don't have any other reasons than performance for switching, you should probably just
look at multi-threading in Ruby or some other optimization.
我致力于使用正确的工具来完成工作。 除非你有绝对的理由将前端连接起来，否则将两者连接在一起绝对没有问题。
I'm all about using the right tool for the job. Unless you have an absolutely dead on reason to port the front, there's absolutely nothing wrong with hooking the two together.