使用 Electron (Atom Shell) 时的客户端/服务器模型是什么?
我正在尝试了解 Electron(以前称为 Atom Shell)的工作原理.
I'm trying to wrap my head around how Electron (formerly Atom Shell) works.
我来自一个传统的 MVC 风格的 Web 应用程序，其中浏览器通过 路由系统 调用 Controller Action，然后控制器从存储(文件系统，数据库，...)并呈现一个 View，它被发送回浏览器.某些 Action 可能会返回 JSON，因为它们是通过 JavaScript/AJAX 调用的，而不是浏览器实际导航到它们.
I'm coming from a traditional, MVC-style web application where a Browser is calling a Controller Action through a Routing System, the Controller then fetches data from a store (File System, Data Base, ...) and renders a View, which is sent back to the Browser. Some Actions may be sending back JSON instead, as they are called through JavaScript/AJAX instead of the Browser actually navigating to them.
我想创建它，但作为跨平台桌面应用程序.我知道 Atom Shell 结合了 Chromium-Browser 和 Node.js/v8 运行时，但我不确定它们将如何通信.
I want to create that, but as a Cross-Platform Desktop Application. I know that Atom Shell combines both a Chromium-Browser and a Node.js/v8 runtime, but I'm not sure how they would communicate.
我想我可以在网络服务器上运行一个完整的服务器(基本上是一些 Node.js HTTP 中间件，例如 Express)，但这会创建一个网络- 可访问的服务器(也可能会触发防火墙) - 我想要制作桌面应用程序的原因之一正是为了避免运行真正的服务器.基本上就像普通"桌面应用程序中的 MVP/MVVM 模式.
I guess I could run a full on web server (basically, some Node.js HTTP Middleware like Express), but that creates a network-reachable server (which might also trip up firewalls) - one of the reasons I want to make a desktop app is precisely to avoid running a real server. Basically like the MVP/MVVM pattern in a "normal" desktop app.
有人可以给我一些我正在尝试做的事情的起点吗?浏览器将如何与节点运行时(他们称之为客户端"?)进行对话以告诉它嘿，获取我的 ID 为 12345 的记录"，客户端会返回呈现的 HTML，还是浏览器只会得到一个 blobJSON 的返回并通过 JavaScript 模板引擎呈现?
Can someone give me a few starting points for what I'm trying to do? How would the browser talk to the node runtime (the "Client" as they call it?) to tell it "Hey, fetch my the record with ID 12345" and would the Client return rendered HTML, or would the browser just get a blob of JSON back and render it through a JavaScript templating engine?
推荐答案
Electron 似乎并没有将 Node.js 用作 Web 服务器，而只是作为运行后台 JavaScript 代码的环境，此代码可以使用 node 模块来访问系统.同时，Chromium 为应用程序提供了一个用户界面，它显示了运行普通沙盒 JavaScript 的常规网页.两者都被 Electron 可执行文件嵌入，前者直接(Node.js 可以构建为静态库)，后者通过 libchromiumcontent.在某种程度上，Node.js 是应用程序的控制器部分，而 Chromium 是视图.
Electron doesn't seem to use Node.js as a web server but merely as an environment to run background JavaScript code, this code can use node modules to access the system. At the same time Chromium provides a user interface for the app, it displays regular web pages that run usual sandboxed JavaScript. Both are being embedded by the Electron executable, the former directly (Node.js can be built as a static library), the latter via libchromiumcontent. In a way, Node.js is the controller part of the application whereas Chromium is the view.
通常，这里用于网页的概念是单页应用程序:一个网页代表一个应用程序窗口，因此只要此窗口可见(通常在应用程序的整个生命周期内)，它就会一直存在.每当它需要显示不同的东西时，它都会从运行在 Node.js 中的后台代码请求数据，就像 AJAX 应用程序从服务器请求数据一样.页面本身不会重新加载，通常会使用 JavaScript 模板来更新内容.
Typically, the concept used for web pages here is that of single-page applications: a web page represents one application window and as such it stays around as long as this window is visible (often for the entire lifetime of the application). Whenever it needs to display something different it requests data from the background code running in Node.js, just like AJAX applications request data from the server. The page itself is not reloaded, usually JavaScript templating will be used to update contents.
这里并没有真正的服务器/客户端关系，但是通信实际上可以双向进行.双方可以使用 ipc 模块相互发送消息(主进程，渲染器).这些消息可以附加任何参数，这些不需要显式编码(通常这是通过在内部使用 JSON 对参数进行编码来实现的，我没有验证 Electron 是否是这种情况).在内部，消息传递是通过平台特定的 IPC 机制实现的，使用 libuv 准确地说.
There isn't really a server/client relationship here however, the communication can actually go both ways. Both sides can use the ipc module to send messages to each other (main process, renderer). These messages can have any arguments attached to them, these don't need to be encoded explicitly (typically this is implemented by using JSON internally to encode parameters, I didn't verify whether that's the case with Electron). Internally, that message passing is implemented via platform-specific IPC mechanisms, using libuv to be exact.
相关文章