创建react应用程序_我是否在我的React Gatsby实时应用程序中使用Heroku，Netlify或Firebase？

创建react应用程序

So the last few weeks, I have been working on creating an application generator for real-time applications. One of the primary requirements is that it needs to include everything out of the gate an application engineer will need. This also means platform deployment.

因此，在过去的几周中，我一直在努力为实时应用程序创建应用程序生成器。 主要要求之一是它需要囊括应用工程师所需的一切。 这也意味着平台部署。

Ok cool. I’ll start with small platforms like Heroku, Firebase and Netlify while I work my way up to the larger AWS, GCP and Azure platforms.

嗯不错。 我将首先从Heroku，Firebase和Netlify等小型平台着手，然后逐步发展到更大的AWS，GCP和Azure平台。

First up — Netlify.

首先-Netlify。

Netlify用于实时应用程序？ (Netlify For Real-Time Apps?)

I’ll be honest. I was excited to work with Netlify as I heard good things about it. It promises to seamlessly hook into your git repository and automatically build and deploy your static sites & cloud functions into the cloud.

老实说 当我听到有关Netlify的美好消息时，我感到很兴奋。 它承诺可以无缝连接到您的git存储库，并自动将静态站点和云功能构建并部署到云中。

No pipelines needed.

无需管道。

Build and deployment. Done for you.

构建和部署。 为你做了。

That makes my life developing an application generator easy. Wipe my hands clean and poof.

这使我简化开发应用程序生成器的工作。 擦净我的手并擦拭。

好处 (Benefits)

• Perfect for Static Site Generated UIs: ok. Netlify is cool. It is really great for deploying static site generated apps. The LunarBaby app generator uses React Gatsby under the hood and It’s great. Netlify knew everything to do. I didn’t have to do any kind of setup at all. Just use their UI to connect to my Gitlab repo and push my code up to master. Netlify did the rest.

  非常适合静态网站生成的UI：确定。 Netlify很酷。 这对于部署静态网站生成的应用程序确实非常有用。 LunarBaby应用程序生成器在后台使用React Gatsby，这很棒。 Netlify知道所有事情。 我根本不需要进行任何设置。 只需使用他们的UI连接到我的Gitlab存储库，然后将我的代码推送到主站点即可。 Netlify完成了其余的工作。

• Cloud Functions done well: Maybe using a bit of a cheat code here but they use AWS Lambda functions under the hood. Turns out that Netlify is pretty much an easy to use wrapper over AWS. That’s fine in my book. Deploying the serverless functions was as easy as building and deploying the static content… Like push your code up to the repo and that’s it easy.

  Cloud Functions做得很好：也许在这里使用了一些作弊代码，但它们在后台使用了AWS Lambda函数。 事实证明，Netlify几乎是AWS上易于使用的包装器。 我的书很好。 部署无服务器功能就像构建和部署静态内容一样容易……就像将代码推送到存储库一样，这很容易。

• Great for local development: I chose to keep my function repo separate from my UI so I didn’t really utilize this functionality to its full potential. But it was pretty slick for the serverless functions. Working locally can be a pain building serverless functions. Netlify takes. your. pain. away.

  非常适合本地开发：我选择将函数库与UI分开，因此我并未真正充分利用此功能。 但是对于无服务器功能来说，它是非常漂亮的。 在本地工作可能是构建无服务器功能的麻烦。 Netlify需要。 你的。 痛。 远。

• Price Be Gouda: Let’s be honest. Platform price is important. We all know that it can spiral quickly out of control when using these PAAS tools. I really liked Netlify’s pricing model. It was free for my needs. If you needed anything complex, it’s still inexpensive. Doesn’t spiral.

  Price Be Gouda：说实话。 平台价格很重要。 我们都知道，使用这些PAAS工具时，它会Swift失去控制。 我真的很喜欢Netlify的定价模型。 对于我的需要，它是免费的。 如果您需要任何复杂的东西，它仍然便宜。 没有螺旋。

缺点 (Drawbacks)

• No Staging Environments and Variables. So you typically have at least 3 main environments. Your local environment. A staging / testing environment and a production environment. This isn’t easily possible with Netlify. Out of the gate, you get only a production environment. Want to do “netlify dev”? It defaults to pulling down production config. You do have the option to setup a Toml file and make some changes to setup a local environment… But staging. That’s a whole different ballgame. You’ve got to square peg. round hole it. Need to setup a different app with custom configuration.

  没有暂存环境和变量。 因此，您通常至少有3个主要环境。 您当地的环境。 暂存/测试环境和生产环境。 使用Netlify很难做到这一点。 出门在外，您只会得到一个生产环境。 想做“ netlify dev”吗？ 它默认为拉下生产配置。 您确实可以选择设置Toml文件并进行一些更改以设置本地环境……但要进行分阶段。 那是完全不同的比赛。 你得挂钉子。 圆Kong的。 需要使用自定义配置设置其他应用。

• No long-living backend services. Functions are nice but real-time web apps will need a websocket to work best. This won’t be possible within Netlify. A realtime application will need an event messaging system. None of this is possible with Netlify. It has a specific use case that it does well. But it isn’t very good at the whole server layer support.

  没有长期的后端服务。 功能不错，但实时Web应用程序需要一个websocket才能发挥最佳作用。 在Netlify中这是不可能的。 实时应用程序将需要一个事件消息传递系统。 Netlify无法做到这一点。 它有一个很好的特定用例。 但是在整个服务器层的支持方面并不是很好。

• Where’s the database and message queue? There’s no out of the gate platform support for database. You can setup an add-on for FaunaDB which is really cool. But it’s another external platform. Same goes for event messaging. Realtime apps must have a way to publish and subscribe to messages. You’ll need another platform to manage that.

  数据库和消息队列在哪里？ 没有对数据库的全面支持。 您可以为FaunaDB设置一个非常酷的插件。 但这是另一个外部平台。 事件消息传递也是如此。 实时应用必须具有一种发布和订阅消息的方法。 您将需要另一个平台来管理它。

总体建议：非常适合JAMstack Apps。 不适用于实时应用。 (Overall Recommendation: Excellent for JAMstack Apps. Won’t Work for Real-Time Apps.)

Right now, if you are building a real-time web application. Don’t use Netlify. It isn’t a good fit for the platform. You will end up in platform hell. I love Netlify for prototyping and certain use-cases. Real-time applications isn’t it.

现在，如果您正在构建实时Web应用程序。 不要使用Netlify。 它不适合该平台。 您将最终陷入平台地狱。 我喜欢Netlify的原型制作和某些用例。 实时应用不是吗。

用于实时应用程序的Heroku？ (Heroku for Real-Time Apps?)

Next up. Heroku. I’ve always had a soft spot for Heroku. It is a great platform for startups and smaller applications. It’s easy to get setup. Add a git remote for the project and push away. Setting up ci / cd pipelines are pretty straightforward. I use it a lot for prototyping and consulting.

接下来。 Heroku。 我一直对Heroku情有独钟。 对于初创企业和较小的应用程序来说，这是一个很好的平台。 设置很容易。 为项目添加一个git remote并推开。 设置ci / cd管道非常简单。 我经常使用它进行原型设计和咨询。

But is it the right tool for the job for real-time apps?

但这是适合实时应用的正确工具吗？

好处 (Benefits)

• Still easy deployment. Heroku is still very easy to deploy. It doesn’t offer the automated build tools that Netlify provides but we’re still a ways from more complicated infrastructure deployment. You can manually do it through a couple of Heroku commands or write a ci/cd pipeline fairly easily. Gitlab & CircleCI (not sure about others) have a template that you can use.

  仍然易于部署。 Heroku仍然非常易于部署。 它没有提供Netlify提供的自动构建工具，但是从更复杂的基础架构部署中我们仍然可以采用这种方法。 您可以通过几个Heroku命令手动执行此操作，也可以相当轻松地编写ci / cd管道。 Gitlab和CircleCI(不确定其他人)具有可以使用的模板。

• Can handle Websockets & back-end services. You can deploy fully functioning microservices into Heroku. This means that you can have websockets for your applications. This is a checkmark here. Heroku doesn’t have FAAS system like Netlify which kinda stinks. But It does have support for the websockets requirements.

  可以处理Websockets和后端服务。 您可以将功能全面的微服务部署到Heroku中。 这意味着您可以为应用程序提供websocket。 这是一个复选标记。 Heroku没有像Netlify这样的FAAS系统有点发臭。 但是它确实支持websockets的要求。

• Does have Kafka support for event messaging. Another checkmark (with a later to come gotcha). Heroku does have an add-on for Kafka. You are very capable of building a whole real-time application within the Heroku platform.

  是否具有Kafka对事件消息的支持。 另一个选中标记(稍后会出现问题)。 Heroku确实为Kafka提供了一个附加组件。 您非常有能力在Heroku平台内构建整个实时应用程序。

缺点 (Drawbacks)

• Price isn’t sustainable: This is generally the case with Heroku but it is almost impossible with real-time applications. The Kafka add-on is $100 / month to start. Most start-ups and consultants who use Heroku is because they need a quick and inexpensive way to get a proof of concept out the door. As they begin to need to scale then they switch to a larger platform. This same option really isn’t available when building a real-time application with Heroku. You’re starting price is $100 / month. And then it quickly jumps as you scale.

  价格不可持续： Heroku通常就是这种情况，但对于实时应用程序几乎是不可能的。 Kafka附加组件的起价为每月100美元。 使用Heroku的大多数初创企业和顾问是因为他们需要一种快速而廉价的方法来获得概念验证。 当他们开始需要扩展时，便会切换到更大的平台。 当使用Heroku构建实时应用程序时，实际上没有此选项。 您的起价为$ 100 /月。 然后，随着缩放，它会Swift跳跃。

总体建议：用Heroku构建实时应用程序可能但不切实际 (Overall Recommendation: Possible but Not Realistic to Build Real-Time Applications With Heroku)

Could you do it? Ya, sure. Should you do it? probably not.

你能做到吗？ 是呀当然。 你应该做吗？ 可能不是。

The not so secret elephant in the room is that Heroku doesn’t scale very well. It works well for startups and small applications but as soon as a project grows to anything of substance, it becomes expensive quick. And, well, real-time apps start out complicated. They aren’t your typical stacks out there. Between websockets and an event messaging system, you’ve got complexity that standard application doesn’t need.

房间里不是那么秘密的大象是Heroku的缩放比例不好。 它适用于初创企业和小型应用程序，但是一旦项目发展到任何实质，它很快就会变得昂贵。 而且，实时应用开始时很复杂。 它们不是您的典型堆栈。 在websocket和事件消息系统之间，您具有标准应用程序不需要的复杂性。

A prototype real-time app on Heroku is starting at $100 / month just for the Kafka service. Just moving from a prototype to a professional app, you’re looking at $200 before you even got your first user.

仅在Kafka服务上，Heroku上的原型实时应用程序起价为100美元/月。 只是从原型开发过渡到专业应用程序，您还需要200美元才能买到第一个用户。

I like Heroku. But it’s not the right tool for the job.

我喜欢Heroku。 但这不是完成这项工作的正确工具。

实时应用的Firebase？ 这是正确的 (Firebase for Real-Time Apps? It’s the right one)

So that leaves one platform standing. Firebase.

这样一来，平台就可以站立了。 火力基地。

Quite simply, it wasn’t a fair fight. Firebase’s Firestore database is built for this use case. It is marketed as a real-time database for mobile and web applications. The platform was made for this challenge.

很简单，这不是一场公平的战斗。 Firebase的Firestore数据库是为此用例构建的。 它作为移动和Web应用程序的实时数据库销售。 该平台就是为应对这一挑战而设计的。

That being said, while Firebase may be the right choice for real-time applications, I do have some concerns about the platform.

话虽这么说，虽然Firebase可能是实时应用程序的正确选择，但我确实对该平台有些担心。

好处 (Benefits)

1. It was built for this use case. Firebase was built as a platform for realtime mobile and web application developers. It has everything you need out of the box and is developer friendly. You don’t have to go through platform hell to build this type of application. Just setup Firebase and you’re good to go.

   它是为此用例构建的。 Firebase被构建为面向实时移动和Web应用程序开发人员的平台。 它具有您开箱即用所需的一切，并且对开发人员友好。 您不必经历地狱就可以构建这种类型的应用程序。 只需设置Firebase，您就可以使用了。

2. Easy build and deploy. This is just the same as both Netlify and Heroku. They all run in the no-ops circle. Firebase has a cli tool that allows you to build, test and deploy your requirements. Integrating with your CI/CD pipelines is just as easy as well. You can have a proof of concept up within a weekend.

   易于构建和部署。 这与Netlify和Heroku相同。 他们全都在无人操作的圈子里奔跑。 Firebase具有cli工具，可让您构建，测试和部署需求。 与您的CI / CD管道集成也同样容易。 您可以在周末内获得概念证明。

3. Price is Gouda. We’re getting back to reality here. The price to concept and push out a real-time application in Firebase is negligible. You are likely not to spend much until you see real traction. between the real-time database, hosting the UI in the buckets, the serverless functions, you won’t be paying anything of significant for awhile. This is important as you grow out your real-time application.

   价格是高达。 我们在这里回到现实。 从概念到在Firebase中推出实时应用程序的价格可以忽略不计。 在看到真正的吸引力之前，您可能不会花很多钱。 在实时数据库，将用户界面托管在存储桶中，无服务器功能之间，您将不会花一会儿时间了。 当您开发实时应用程序时，这一点很重要。

4. Firebase really is just Google Cloud Platform. When you’re using Firebase services, you’re actually using GCP services. Firebase is just a useful way to interact with GCP for web & mobile app developers. It provides a no-ops platform. But the entire Firebase suite of tools is available within the larger Google Cloud Platform ecosystem. This means, you’ll avoid platform hell as you need additional resources.

   Firebase实际上只是Google Cloud Platform。 使用Firebase服务时，实际上是在使用GCP服务。 对于网络和移动应用程序开发人员而言，Firebase只是与GCP进行交互的一种有用方法。 它提供了一个无操作平台。 但是，整个Firebase工具套件可在更大的Google Cloud Platform生态系统中使用。 这意味着，由于需要更多资源，您将避免平台混乱。

缺点 (Drawbacks)

1. Firebase really is just Google Cloud Platform. Salesforce owns Heroku. Netlify is just a wrapper around AWS but Firebase projects are actually Google Cloud Platform projects. It can be good or bad but you’re basically tying yourself into a larger platform as your application grows. It’s a brilliant move by Google. Is it a good move for you?

   Firebase实际上只是Google Cloud Platform。 Salesforce拥有Heroku。 Netlify只是AWS的包装，但Firebase项目实际上是Google Cloud Platform项目。 可能是好是坏，但是随着应用程序的增长，您基本上将自己束缚在更大的平台上。 这是Google的绝妙举动。 这对您来说是个好举动吗？

2. Firestore scares me. Firestore real-time database is really cool. But it’s also a bit scary. It is pretty bad practice to pipe your database all the way through a web UI. It is generally too dangerous. This is exactly what firebase recommends. Interact with Firestore directly from your web UI. I will disclaimer that they do have pretty powerful firewalls and rules preventing shady access. In addition, we probably aren’t working directly with the database but some api wrapper around it. It still is worrisome to me.

   消防站吓到我了。 Firestore实时数据库真的很棒。 但这也有点吓人。 完全通过Web UI传递数据库是非常糟糕的做法。 通常太危险了。 这正是Firebase的建议。 直接从您的Web UI与Firestore进行交互。 我将声明它们确实具有功能强大的防火墙和规则，可防止不正当访问。 另外，我们可能不直接与数据库一起使用，而是围绕它进行一些api包装。 我还是很担心。

3. Firestore scares me. Yes. you read that right. I repeated myself. Firestore is a very unique document database. I haven’t encountered any other database that uses the same paradigm. If you were to switch to a different document store, you’ll will need to trash the storage logic and start over. It is also becomes quite difficult to manage schema and relationships as your application domain grows. Mongo doesn’t handle relationships all that well but it does provide better solutions than Firestore. With Firestore, they basically say. create 2 additional relationship collections in addition to your 2 primary collections when you want to do Many to Many relationships. Say what?

   消防站吓到我了。 是。 你没看错。 我重复了自己。 Firestore是一个非常独特的文档数据库。 我还没有遇到其他使用相同范例的数据库。 如果要切换到其他文档存储，则将需要破坏存储逻辑并重新开始。 随着应用程序域的增长，管理架构和关系也变得非常困难。 Mongo不能很好地处理关系，但是它确实比Firestore提供更好的解决方案。 他们基本上说使用Firestore。 当您想进行多对多关系时，除了您的2个主要集合外，还要创建2个其他关系集合。 说什么？

4. Firestore scares me. Ok. I did it one more time. Firestore is a proprietary database service. This means you can’t have a dockerized version on your local environment. You’re stuck using the Firestore web service. This may not be a terrible thing for your needs but I really don’t like my database being locked into a particular vendor forever.

   消防站吓到我了。 好。 我又做了一次。 Firestore是专有的数据库服务。 这意味着您在本地环境中无法使用dockerized版本。 您在使用Firestore Web服务时陷入困境。 对于您的需求而言，这可能不是一件可怕的事情，但我真的不希望我的数据库永远被锁定在特定的供应商中。

总体建议：启动实时应用程序的理想选择 (Overall Recommendation: Ideal for Starting Real-Time Applications)

In the end, Firebase is the right solution to start your real-time applications within the noOps space. You have everything that you need at your disposal. It is true that you need to be cautious with vendor lock-in with Firebase but this can be be managed with good application architecture. You don’t want to be stuck 3–5 years down the road needing to rearchitect your entire application because you’re stuck with an infrastructure vendor. It’ll be a very expensive fix.

最后，Firebase是在noOps空间内启动实时应用程序的正确解决方案。 您拥有所需的一切。 的确，您需要谨慎使用Firebase进行供应商锁定，但是可以使用良好的应用程序体系结构进行管理。 您不想在需要重新构建整个应用程序的路上停留3-5年，因为您被基础设施供应商所困扰。 这将是一个非常昂贵的修复程序。

Do it right from the start. Build your application architecture so you can swap any platform with as little effort as possible. It is faster to build something that does have vendor lock-in but that extra little bit of time is going to save you a lot of time and money down the road.

从一开始就做。 构建您的应用程序体系结构，以便您可以轻松交换任何平台。 构建具有供应商锁定功能的产品更快，但是额外的一点时间将为您节省大量的时间和金钱。

最初发布：LunarCollective.io (Originally Published: LunarCollective.io)

This article was originally published at https://LunarCollective.io. We’re a group of digital professionals collaborating together to help build each other up and make awesome products. Learn more here

本文最初发表于https://LunarCollective.io。 我们是一群数字专业人士，他们共同合作，互相帮助，共同打造出令人敬畏的产品。 在这里了解更多

翻译自: https://levelup.gitconnected.com/do-i-use-heroku-netlify-or-firebase-for-my-react-gatsby-realtime-application-1797557a1153

创建react应用程序