vulcan 编程_如何用Next代替流星— Vulcan Next Starter简介

vulcan 编程

2020年，仍在寻找高效的JS框架 (2020, still looking for a productive JS framework)

When you create a product for your own company, you are free to spend time setting up a development environment that fits your own quirks. Granted, you'll likely spend a reasonable amount of time.

在为自己的公司创建产品时，您可以自由地花费时间来建立适合您自己的怪癖的开发环境。 当然，您可能会花费合理的时间。

But when developing for others, you don’t have this freedom. You have to deliver high quality code in a predictable amount of time.

但是，在为他人发展时，您没有这种自由。 您必须在可预测的时间内交付高质量的代码。

To be competitive, you have to scale across clients. Each app can’t be your first app. Knowledge, and generic code, must be reused. Most of the time that means relying on frameworks.

为了提高竞争力，您必须在客户之间扩展。 每个应用都不能是您的第一个应用。 知识和通用代码必须重复使用。 在大多数情况下，这意味着依赖框架。

As an agency owner, I’ve always loved Meteor. It’s one of the rare JavaScript frameworks that's truly productivity-focused: a package-first architecture, an isomorphic approach, a persistence solution out-of-the-box…

作为代理店老板，我一直很喜欢Meteor。 它是真正以生产力为中心的罕见JavaScript框架之一：包优先的架构，同构方法，开箱即用的持久性解决方案……

I am also a core contributor of Sacha Greif’s Vulcan.js framework. Vulcan is an opinionated full-stack framework, implemented as a super-set of Meteor. It goes one step further by providing declarative patterns for very fast development and relying on Apollo GraphQL.

我还是Sacha Greif的Vulcan.js框架的核心贡献者。 Vulcan是一个自以为是的全栈框架，是Meteor的超集。 通过提供用于快速开发的声明性模式并依靠Apollo GraphQL，它又向前迈进了一步。

Everything (GraphQL schema, API, database structure, forms, data tables, and so on) is automatically generated based on a JavaScript schema. Cool, isn’t it?

一切(GraphQL模式，API，数据库结构，表单，数据表等)都是基于JavaScript模式自动生成的。 不错，不是吗？

But Meteor's limitations are a glass ceiling. I’ve had successful projects with Meteor and Vulcan, but I could never push those frameworks to bigger clients. Too many scalability issues, lack of traction, poor test tooling, you name it.

但是流星的局限性是玻璃天花板。 我曾与Meteor和Vulcan合作过成功的项目，但我永远无法将这些框架推向更大的客户。 您会说出太多的可伸缩性问题，缺乏吸引力，测试工具不佳。

Back to square one, I needed to find a framework I could get married with.

回到正题，我需要找到一个可以结婚的框架。

下一个vs流星？ (Next vs Meteor?)

那是在比较苹果和橘子！ (That’s comparing apples and oranges!)

When I first discovered Next back in 2017, it was a promising front-end-only framework. Front-end-only. I used it to build my company website and then forgot about it.

当我在2017年首次发现Next时 ，它是一个有前途的仅前端框架。 仅前端。 我用它来建立我的公司网站，然后忘记了它。

And then, people around me started to act weird. They suddenly talked about two frameworks with nothing in common, Meteor and Next, as if they were swappable. You traded Meteor for Next? Why not replace Express by Create React App while you’re at it?

然后，我周围的人开始表现得很奇怪。 他们突然谈论了两个没有共同点的框架，即Meteor和Next，好像它们是可交换的。 您将Meteor换成Next？ 为什么不在时用Create React App替换Express？

As far as I remember, Reaction Commerce has been one of the first non trivial frameworks to do the switch.

据我所知， Reaction Commerce是第一个进行此转换的重要框架。

I wasn’t convinced. And indeed, they still had to implement a GraphQL API on top of their Meteor app to communicate with their Next front end. Trading one framework for 2 is not the best bargain, so we kept Vulcan a Meteor-based framework.

我没有被说服。 实际上，他们仍然必须在Meteor应用程序的顶部实现GraphQL API才能与Next前端进行通信。 用一个框架交换2并不是最好的讨价还价，因此我们让Vulcan保持了基于Meteor的框架。

If you think that comparing Meteor to Next is comparing apples and oranges, you are not that wrong. To this day, Next's catchphrase is still “The React framework”. Not “The Node framework”.

如果您认为将“流星”与“下一步”进行比较就是比较苹果和橙子，那您就没错。 时至今日，Next的口号仍然是“ The React framework”。 不是“节点框架”。

And yet, I started to change my mind a few months ago.

然而，几个月前，我开始改变主意。

使用API​​路由从前端到完整堆栈 (From front end to full stack with API routes)

API routes were officially introduced in July 2019 with the v9 release.

API路由于v9版本于2019年7月正式引入。

That’s what got me on the Next bandwagon again. API routes mean that Next.js is now a minimalistic, but perfectly viable full-stack framework.

那就是让我再次参加Next潮流的原因。 API路由意味着Next.js现在是一个简约但完美可行的全栈框架。

Vulcan is built around GraphQL. And GraphQL is a great fit for API routes. The API is served through a unique, dynamic /graphQL endpoint. In Next, this translates by creating a graphql.js API route. Easy peasy.

Vulcan围绕GraphQL构建。 GraphQL非常适合API路由。 该API是通过唯一的动态/ graphQL端点提供的。 在下一步中，这通过创建graphql.js API路由进行转换。 十分简单。

如今，Next涵盖了从静态到完整堆栈的全部范围 (Nowadays, Next covers the full spectrum from static to full stack)

Next is more and more referred to as a “hybrid framework”. That makes sense, as its versatility is extreme.

接下来越来越多地被称为“混合框架”。 这是有道理的，因为它的多功能性极高。

• You can develop a full-stack application with a serverless-style back end.
  您可以开发具有无服务器风格后端的全栈应用程序。
• You can develop a SaaS application with dynamic server-side rendering.
  您可以使用动态服务器端渲染开发SaaS应用程序。
• You don’t want to maintain a server? You can follow the JAMstack philosophy, and export a static app with build-time server-side rendering.
  您不想维护服务器？ 您可以遵循JAMstack的理念，并使用构建时服务器端渲染导出静态应用程序。
• If you are allergic to client-side JS, you can go as far as removing JavaScript from the bundle and keep only HTML code.
  如果您对客户端JS过敏，则可以从捆绑中删除JavaScript，并仅保留HTML代码。

But don’t think Next is a jack of all trades. It’s a serious contender with Gatsby in its static form. It’s a promising alternative to Meteor in its full-stack form. Vercel (ex Zeit) has been doing a tremendous job at keeping it both high quality and very lightweight, whatever the use case.

但是不要以为Next是万事通。 它是静态的Gatsby的真正竞争者。 它是完整版流星的有前途的替代品。 无论用例如何，Vercel(前Zeit)在保持高质量和轻巧性方面一直做着出色的工作。

不要掉落流星 (Don’t drop Meteor yet)

I want to make something clear. Replacing Meteor by Next as our core framework in Vulcan does not mean we think Meteor should be dropped altogether.

我想澄清一点。 用Next取代Meteor作为Vulcan的核心框架并不意味着我们认为应该完全放弃Meteor。

There is one big thing we learned from our experiments with Apollo and Meteor in Vulcan: if you plan to use Meteor, just embrace the way it works. Forget about GraphQL. Forget about Webpack. Though created by the same people, Apollo and Meteor conflict a lot. It feels weird for GraphQL developers, it feels weird for Meteor purists.

我们从对Vulcan的Apollo和Meteor进行的实验中学到了一件大事：如果您打算使用Meteor，只需拥抱它的工作方式即可。 忘了GraphQL。 忘了Webpack。 尽管由同一个人创造，但阿波罗和流星冲突很多。 对于GraphQL开发人员来说很奇怪，对于流星纯粹主义者来说很奇怪。

Use DDP, methods, pub/sub, learn how to scale your app, join the forum, buy coffee mugs with Meteor’s logo on them. Now that Tiny has revived Meteor, it’s a safe bet for the years to come.

使用DDP，方法，发布/订阅，学习如何扩展应用程序，加入论坛，购买带有Meteor徽标的咖啡杯。 现在，Tiny已使Meteor复活 ，这是未来几年的安全赌注。

With Vulcan + Next, we simply strive to provide a GraphQL alternative to Meteor. It’s not worst or better, it’s the same philosophy with a different implementation.

使用Vulcan + Next，我们只需努力提供GraphQL替代Meteor。 这不是最坏的情况，也不是更好的情况，这是相同的理念，只是实现方式不同。

A framework is like a music instrument. Don’t pick the trendiest, pick the one that fits you. If your instrument is Meteor, go for it.

框架就像乐器。 不要选择最时髦的东西，而要选择适合您的那个。 如果您的乐器是流星，那就去吧。

介绍最新的Next应用程序Vulcan Next Starter (Introducing Vulcan Next Starter, a state-of-the-art Next application)

Using Next out of the box is perfectly fine. You get a build system, a styling solution, a rational folder structure.

开箱即用地使用Next非常好。 您将获得一个构建系统，一个样式解决方案，一个合理的文件夹结构。

But if you want to build an app for the next billion dollar startup, you’ll probably need a few more tools. Remember, we are seeking for a productivity-first alternative to Meteor.

但是，如果您想为下一个十亿美元的创业公司构建应用程序，则可能需要更多工具。 请记住，我们正在寻求以效率为先的替代Meteor的方法。

A cool setup could be this one:

一个很酷的设置可能是这样的：

• Cypress and Jest for unit and e2e testing
  赛普拉斯和Jest用于单元和端到端测试
• Storybook for visual testing and design documentation
  用于视觉测试和设计文档的故事书
• Internationalization, alias i18n (especially if you are from France like me :))
  国际化，别名为i18n(特别是如果您像我这样来自法国:)
• TypeScript, to express your domain model through static types
  TypeScript，通过静态类型表示您的域模型
• Material UI to get a solid set of customizable core components
  实质性的用户界面，以获得一套可靠的可定制核心组件
• Apollo Client to communicate with GraphQL APIs
  Apollo客户端与GraphQL API通信
• Optionally, Apollo Server to setup a GraphQL entry point, with Playground and Voyager for API exploration
  (可选)Apollo Server设置GraphQL入口点，使用Playground和Voyager进行API探索

Next provides a handful examples in its core repo. But that’s not enough in a real life context. These tools can interact altogether in unexpected way.

Next 在其核心仓库中提供了一些示例 。 但这在现实生活中还不够。 这些工具可能以意想不到的方式进行交互。

Typing client-side only components like Leaflet or Plotly may prove difficult. Same goes for unifying the build system of Next, Jest and Storybook, or avoiding bad interactions between Apollo and Material UI during server-side rendering. Redirection with SSR means handling server and client scenarios jointly. I18n is especially hard to set up on its own. And the list goes on.

仅键入客户端组件(例如Leaflet或Plotly)可能很困难。 统一Next，Jest和Storybook的构建系统，或避免在服务器端渲染期间Apollo和Material UI之间的不良交互也是如此。 使用SSR进行重定向意味着共同处理服务器和客户端方案。 I18n特别难以自行设置。 而这样的例子不胜枚举。

Trust me, you don’t want to tackle such issues alone. And guess what? We’ve gone through the hassle for you!

相信我，您不想一个人解决这些问题。 你猜怎么着？ 我们为您解决了所有麻烦！

All those tools are installed in our new, shiny, Vulcan Next Starter.

所有这些工具都安装在我们新的，闪亮的 Vulcan Next Starter中 。

We still have a long road ahead, but we are proud to say that it’s safe to use in production.

我们还有很长的路要走，但是我们很自豪地说，在生产中使用它是安全的。

下一步 (Next steps)

Our boilerplate fulfills only half our promise. You get a cool front-end setup, but still miss a database and guidelines to implement the back end. That’s not really comparable to Meteor at this point. A handful of lambdas is not a framework. Neither is subscribing to cloud-hosted solutions.

我们的样板只履行我们承诺的一半。 您获得了一个不错的前端设置，但是仍然缺少数据库和实现后端的准则。 在这一点上，这真的不能与流星相提并论。 少数lambda并不是框架。 两者都没有订阅云托管的解决方案。

That’s where Vulcan comes in. Through the years, we have crafted a powerful GraphQL API generator, with Mongo as the database and tons of front-end utilities. Naturally, the next step for us is to combine both Vulcan and Next to create a true full-stack framework.

这就是Vulcan的用武之地。这些年来，我们精心设计了功能强大的GraphQL API生成器，使用Mongo作为数据库和大量的前端实用程序。 自然，下一步是将Vulcan和Next结合起来，创建一个真正的全栈框架。

You can follow our progress by joining us on Vulcan’s Slack.

您可以通过加入Vulcan的Slack来跟踪我们的进展。

Next and Meteor will be first-class citizens of Vulcan, but any kind of JS front-end or back-end technology could enjoy it. Be it Gatsby or a custom Node micro-service. At Vulcan, we sell apples AND oranges, as long as they make you an efficient developer.

Next和Meteor将成为Vulcan的一等公民，但是任何一种JS前端或后端技术都可以享受它。 无论是Gatsby还是定制的Node微服务。 在Vulcan，我们出售苹果和桔子，只要它们能使您成为高效的开发人员即可。

Now, it’s time for us to get back to work, we have a lot to do. Hope to see you at Vulcan!

现在，我们该回到工作了，我们还有很多工作要做。 希望在火神见到你！

来自战es的首发 (A starter from the trenches)

Special thanks to Aplines, who trusted my company (LBKE) in using the latest technologies for their product. Thanks to them, we’ve tested all features included in Vulcan Next Starter altogether in a real-life professional application.

特别感谢Aplines，他信任我的公司(LBKE)将最新技术用于他们的产品。 多亏了他们，我们才在真实的专业应用程序中测试了Vulcan Next Starter中包含的所有功能。

They are looking for developers, so if you want to learn more about using Next and GraphQL at scale, that’s the place to go: [e-mail]

他们正在寻找开发人员，因此，如果您想了解有关大规模使用Next和GraphQL的更多信息，可以去这里： [e-mail]

翻译自: https://www.freecodecamp.org/news/how-to-replace-meteor-by-next-introducing-vulcan-next-starter/

vulcan 编程