【问题标题】:Choosing a framework for both app and website [closed]为应用程序和网站选择框架 [关闭]
【发布时间】:2016-11-23 04:59:09
【问题描述】:

有一个旧的 php 基础网站,它提供单一服务并且已经工作了很多年。现在我们决定改变网站本身,使其变得更现代、更快捷,同时为其提供应用程序,我们将为此聘请一些人。由于我自己是一名开发人员(一个 c++/go 粉丝,主要是在机器学习领域),所以我想知道在需要这种东西时选择什么是最好的选择。我个人认为整个后端应该作为一个 RESTful API 工作,然后可能在前端为 web 和移动设备使用 react 和 react-native,但我不确定这是否是我们可以做出的最佳决定。

我想知道有相同要求的其他人做了什么?有人向我们推荐了流星,但它似乎变化很快,我们确实需要一些稳定成熟的解决方案,无需过多维护。

期待听到您的建议

【问题讨论】:

  • 这个问题本身就很自以为是,没有任何答案显然是最好的。也就是说,对于前端,如果我需要广泛的应用程序支持,我今天会考虑的一个选项是将节点工具用于基于 Web 的界面,使用 React 和 material-ui 或 bootstrap@4,然后将 Cordova 用于 iOS/Android 和 electron 用于 Windows/Mac/Linux 支持。大多数代码库都可以广泛重复使用,并且几乎可以针对所有常见的原生平台。
  • 感谢您的评论,是的,这是固执己见,但这正是我正在寻找的,因为每个人都有一个选项,这让我可以找到更多关于我不知道的替代方案。老实说,我在这个话题上搜索了一周,得到的信息太少了。现在我正在尝试列出所有选项,然后尝试找出成本(寻找开发人员、服务器等)、可维护性、稳定性以及每个选项的更多因素来决定使用哪个选项。

标签: rest reactjs meteor web-applications react-native


【解决方案1】:

我是 REST API + 前端 JS 框架架构的忠实粉丝。

一种选择是使用 Ruby on Rails 构建 API。 “rails generate new”命令包括一个 --api 选项,用于生成缺少视图并提供 JSON 的 Rails 应用程序。您可以在 rails-api gem GitHub 页面了解有关使用 Rails 构建 API 的更多信息。 (请记住,rails-api gem 已经被滚动到 Rails 中。)

总的来说,Rails 是一种快速启动和运行服务层的方法。它相当简单,对于您的应用程序来说可能是一个不错的选择,正如您所说,它只提供一项服务。不过,Rails 也足够强大,可以支持更丰富的 API。

如果您想要一个非常简单的基于 Ruby 的服务层,您应该查看Sinatra。您也可以使用 Express 来使用完整的 Javascript。就像 Sinatra 一样简单。

如果您有 C++ 和 Go 的背景,您可能不想一头扎进这些网络密集型技术。考虑将 Java Spring 用于您的服务层。 (我会链接,但我没有足够的代表。哈哈)

就前端而言,您使用 React 和 Meteor 走在了正确的轨道上。我个人是 Angular(特别是 Angular 2)的粉丝。这是一个非常流行的 JS Web 应用程序框架——非常适合异步 Javascript 和单页应用程序。诚然,Angular 有一个陡峭的学习曲线,但如果你愿意爬上去,它就会有回报。

如果您有任何具体问题,请告诉我!祝你好运。

【讨论】:

  • 所以如果我想使用 Go 那么你对后端的建议是什么?
  • 我对 Go 没有任何经验,但我发现了一些关于使用该语言构建 REST JSON API 的好资源。[这描述了 (golang.org/doc/articles/wiki/#tmp_3) 和
  • 对不起,我还没说完!无论如何,我对 Go 没有任何经验,但我发现了一些关于使用该语言构建 REST JSON API 的好资源。 This blog post 是一个很好的介绍。
【解决方案2】:

如果你想要的只是一个网站,Meteor 就有点重了。这取决于你想要多少交互性 - 如果它更像是一个应用程序,那么它是值得做的,如果你想做 ios 和 android 应用程序,那么 Meteor 的启动和运行速度非常快。

我建议您选择一项您热衷于学习或者您已经具备一些技能的技术。学习曲线意味着更长的项目。

【讨论】:

  • Meteor 有 2 个问题。首先,他们似乎正在快速改变事物,比如放弃 blaze 并开始做出反应,然后现在他们正在放弃 DDP 去 Apollo,第二个是开发人员的数量,因为正如我所说,我们需要雇佣开发人员和许多 js 开发人员假装知道 Meteor 对 js 本身不是很熟悉!
  • 我不认为“放弃 DDP”是一个有效的说法。 Javascript 世界正在快速发展,不仅仅是 MDG 这样做,Angular 刚刚进入 v2,React 实际上还没有达到 1.0。 Apollo 为您提供更多选择。我承认 Meteor 开发人员的数量仍然很少,但 Meteor 仍然在 Github 明星列表中排名靠前
  • 来自 MDG 的 DeBergalis 在 Meteor 1.4 及其他会谈中提到:“我们致力于一条让您能够一起使用这些不同部分的路径,因为我们找出了过渡的正确时间Apollo 将成为新的默认数据层。”所以大多数人认为未来 DDP 会像 blaze 一样交给社区寻求支持。
  • 他说的是数据层,不是数据协议。
  • 是的,但是由于 apollo 可以在 http 上工作,因为流星曾经决定不拥有自己开发的前端,然后他们许多人可能会认为 DDP 会再次发生同样的事情。当然,它可能根本不会发生。正如你所说,整个 javascript 世界正在快速发展,这就是为什么我有点担心流星。而且我忘了回复学习曲线部分,我们将雇用人员来完成项目的大部分工作,所以我只需要学习基础知识就能理解什么和为什么。
【解决方案3】:

如果您需要原生移动应用程序和交互式站点,那么使用纯 API 服务器的 reactreact-native 是一个非常好的解决方案。我开发了几个类似的服务,对这种组合非常满意。

首先,您可以在两个客户端之间共享 API 访问层和部分业务逻辑。
其次,您在移动设备和网络上使用相同的技术。然而,移动应用程序具有真正的原生 UI,因为 React Native 不使用浏览器。
第三,服务器变得更加简单、可维护和可扩展。

我个人更喜欢 WebSockets 作为网络协议(看看令人惊叹的 Go gorilla websocket 实现)。但是,如果您需要支持旧浏览器或者更喜欢更经典的 REST API,也可以。

【讨论】:

  • 谢谢,对于后端你有什么建议? Go, JS, Python , ... 我见过 Go gorilla 但由于我自己是 Go 开发人员(不是 Go Web 开发人员)我知道在编写 Go 后端时存在一些问题,例如当你想要通过代理发送 GET 请求,Go 默认使用环境代理,很难找到任何实现简单代理管理的替代包。我更喜欢使用 Go,但我不确定是否有其他替代方案可以在提供良好稳定性的同时大大降低成本。
  • 所有这些选项都可以。 Go 在后台运行良好。这是开发这种语言的目的之一。部署非常快速和简单(您知道一个二进制文件)。 Gin 或 Gorilla 将是 REST API 的不错选择。 Python 有大量有用的库。如果你会选择这种语言,试试 Flask。如果您决定使用完整的 javascript,请查看 Sails。如果您需要更多低级控制,请使用 Express 或 Koa。当然,如果您需要更多交互级别,您将需要另一个库和框架。对于节点,它可以是 deepstream、Apollo、Feathers、Kuzzle 或其他取决于您的需要。
【解决方案4】:

根据我上面的评论回答,这都是固执己见,但我发现 Node/JavaScript 往往是物有所值的最佳选择,如果您要做的只是通过概念验证阶段,并且可能从那里扩展。根据您的后端需求,您可能希望将部分或整体迁移到 Go 或 Python。

在前端,使用 web 工具(主要以 node 和 npm 为中心),我将使用 React 和 material-ui 组件构建主 UI...针对 web/浏览器界面...然后您可以扩展这是为了支持更多类似原生的功能。您可以使用适用于 Android 和 iOS 的 Cordova 构建“本机”版本。您可以使用 electron 作为桌面版本的基础。

对于后端,node 是一个不错的起点,我觉得 RethinkDB 对于许多用例来说是一个很棒的数据库(尽管现在正在发生从商业平台到开放平台的变化)。 Mongo 是另一种选择,通过一些提供商提供托管/托管选项。或者,我可能会倾向于通过 Amazon 使用 PostgreSQL。

API 服务器,我肯定会先使用 Node发展方面。如果您在某些领域需要比性能更高的灵活性,Python 有非常丰富的工具。还有其他选择,C# 正在成为一个非常好的跨平台选择,我碰巧真的很欣赏它作为一门语言。那里的性能非常好,尽管您可能会发现一些约束不如 JS 或 Python 有吸引力。

YMMV 与这些选择中的任何一个。

【讨论】:

  • 你会选择什么框架来使用 node 创建 API? (带有节点的选项比其他选项多很多倍)
  • React 之后推荐 Cordova 很奇怪。 React Native 会是更好的选择。它速度更快,并且具有真正的原生 UI。我也警告不要使用 RethinkDB。 RethinkDB 公司于 10 月关闭,该项目的未来不确定。
  • 建议是因为您将能够使用 Cordova 获得比使用 ReactNative 更多的代码重用(视图)...如果您愿意,您应该能够重用状态管理和接口使用 Redux 之类的东西进行控制流,但是 UI 和许多集成点在 ReactNative 和 Desktop 中会有所不同。除非你将 MacNative 和 Reactnative 用于 UWP(windows),它们仍然会有很多差异。
  • 除此之外,大多数应用程序在 Cordova 下都运行得很好,但它对于很多用途来说并不是很好......这将取决于。
猜你喜欢
  • 1970-01-01
  • 2013-06-09
  • 1970-01-01
  • 1970-01-01
  • 2011-01-30
  • 2012-06-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多