整理 | 彭慧中 责编 | 屠敏
出品 | CSDN(ID:CSDNnews)
Ruby语言曾在2013至2015年期间非常流行,但随后流行度下降。早在3年前就在业界传出过**“Ruby及Ruby on Rails已死”**的言论,然而时至今日,连GitLab的CEO Sid Sijbrandij都发文表示:Ruby on Rails仍然是GitLab的坚定选择。那么,这项正走向没落技术究竟具有何种魔力?
“两全其美”的Ruby on Rails
Ruby on Rails(官方简称为Rails,亦被简称为RoR),是一个使用Ruby语言写的开源Web应用框架。Rails的设计原则包括“不做重复的事”(Don’t Repeat Yourself)和“惯例优于设定”(Convention Over Configuration),因此一经发布便被不少开发者及大厂采用。
不过,回忆最初创建Ruby on Rails的经历,创始人David Heinemeier Hansson称因受PHP、Java两种语言的影响,在开发时有些犹豫不决。一方面,他不喜欢Java的运行速度低且灵活性低,因为这会让Web框架变得复杂和难以使用,但Java结构的完整性却让他欣喜不已。另一方面,他喜欢PHP的“新手友好”,但又不太喜欢PHP导致Web框架混乱不堪的结构。
这似乎很难做到两全其美。要么选择“新手友好”但杂乱无章的PHP,要么选择结构良好但难以使用的Java。
这好像就是在曾经的服务器类操作系统(如Unix)和客户端操作系统(如Windows和MacOS)之间进行抉择,前者稳定但难以使用,后者简单易用但经常崩溃。
在过往尝试的过程中,似乎每个人都接受了这种“非黑即白”的选项,直到后来乔布斯带来了NeXTSTEP操作系统,它在稳定的Unix基础上推出了漂亮的、平易近人的、光滑的图形用户界面。如今,“服务器级”的Unix不仅可以运行漂亮的GUI桌面,还可以运行大多数手机和智能手表。
因此,事实证明操作系统的“简单易用”和“不稳定”实际上并无关联,而网络框架的“新手友好”和“结构混乱”也是如此,它们彼此独立。
想通了这一点,由David Heinemeier Hansson创建的Ruby on Rails应运而生,这正是一款极其“新手友好”并且具有良好结构的网络框架。而Ruby也被证明是Ruby创始人用Rails来实现上述要求的理想载体。
Rails与GitLab不谋而合
当GitLab的联合创始人Dmitriy Zaporozhets决定建立GitLab时,他选择了Ruby on Rails,尽管当时他主要使用PHP。Dmitry的选择或许有先见之明,又或许只是偶然,但Rails确实为GitLab提供了非常好的服务,其中很大一部分原因是David成功地实现了他对Rails的目标:简单易用且结构良好。
Rails使GitLab能够开发出模块化的单体。模块化单体则是一个结构良好、架构完善、高度模块化的程序,以单一进程的方式运行,并且保持这种尽可能“枯燥”的方式。
模块化单体将GitLab的以开放为核心业务模式从一个漂亮的理论变成了现实。因为,为了获得开源的真正“好处”,贡献者所提供的源代码必须具有吸引力。为了在面对各种来源的贡献时保持架构的完整性,并在开放和封闭的组件之间保持清晰的分界线,这样的代码必须具有非常好的结构。而通过模块化单体,用户和其他第三方开发者为核心产品贡献了附加功能,同时兼具无与伦比的创新速度和可扩展性。
**Rails框架的组织化、结构化风格与GitLab的核心使命相一致。**因为Rails是精简的,所以任何人都可以加入GitLab并参与进去,这使得它从一开始就对GitLab的CEO Sid Sijbrandij具有特别的吸引力。
"我们的使命是每个人都能做出贡献。而Ruby on Rails恰好‘新手友好’,它遵循所有的原则与习惯,并且没有其他扩展等各种花哨的内容。我认为,GitLab的首要价值是提供了一个非常好的开源代码库。而次要的价值则是提供了这样一套“枯燥”的解决方案:不做任何花里胡哨的事情,以便让每个人能够在这个代码库之上进行创造。真的很感谢Ruby为我们提供了这样一个稳定的生态系统。”Sid说道。
虽非完美,但“瑕不掩瑜”
尽管Rails是非常好的技术,但依然存在美中不足之处,**其中之一就是性能。**然而大多数代码库中只有一小部分对性能的要求较高。对此,GitLab的开发人员已经通过多种方式来改善性能,包括用Go重写代码和使用Vue框架。Go被用来解决影响加载时间的其他问题,并减少内存使用。而VUE被用来重写频繁访问的页面,如问题和合并请求,因此它们加载得更快,改善了用户体验。
Sid表示:“Ruby是服务于开发者的,而不是为了在生产中运行它。对于那些经常被攻击的、对性能要求高的,或是那些必须在系统IO上等待很长时间的部分,我们用Go进行了重写。与此同时,我们仍然在努力使GitLab占用更少的内存,因此,我们需要启用多线程。尽管它不会让开发速度变得快得惊人,但至少会减少一部分内存的使用。”
参考资料:https://thenewstack.io/why-were-sticking-with-ruby-on-rails-at-gitlab/