diff --git a/app-guides/kong-api-gateway.mdx b/app-guides/kong-api-gateway.mdx index 6ae1076e01..561f6f60b7 100644 --- a/app-guides/kong-api-gateway.mdx +++ b/app-guides/kong-api-gateway.mdx @@ -10,7 +10,7 @@ import ObsoleteDocSnippet from '/snippets/obsolete-doc.mdx'; Microservices have gained widespread adoption in the past decade, but they present their own set of challenges. Traffic control, authentication, logging, and rate limiting are essential in distributed architectures, but not easy to manage when your organization runs dozens or hundreds of APIs. -[Kong](https://konghq.com/kong/) provides an excellent solution to these problems. It's an open-source API gateway that sits between your users and backend services. By proxying requests through Kong, you can enforce standardized authentication rules, log requests and errors, and even transform data on the fly. +[Kong](https://konghq.com/kong/) provides an excellent solution to these problems. It's an open source API gateway that sits between your users and backend services. By proxying requests through Kong, you can enforce standardized authentication rules, log requests and errors, and even transform data on the fly. Kong can be deployed to a central server, but this slows down your application because all your web requests must pass through a central location before being sent to your backing services. Fortunately, you can take advantage of [Fly's edge hosting model](https://fly.io/) to improve performance by serving Kong on Fly's globally distributed network. diff --git a/blueprints/shared-nothing.mdx b/blueprints/shared-nothing.mdx index 9142ae5f49..2b9a0bb386 100644 --- a/blueprints/shared-nothing.mdx +++ b/blueprints/shared-nothing.mdx @@ -299,7 +299,7 @@ you can go a long way with old-fashioned scripting using the [flyctl](/flyctl) command. -Now lets look at what happens when I create a new event, in a new region. I (a human) get an email, I bring up my admin UI (on an instance of the index app I mentioned above). I fill out a form for the new event. I go to a separate page and add a new region. I then go to a third form where I can review and apply the changes. This involves regenerating my map, and I need to update the NGINX configuration in every existing region. There are shortcuts I can utilize which will update files on each machine and reload the NGINX configuration, but I went that way I would need to ensure that the end result exactly matches the reproducible result that a subsequent `fly deploy` would produce. I don't need that headache, so I'm actually using `fly deploy` which can add tens of seconds to the actual deploy time. +Now lets look at what happens when I create a new event, in a new region. I (a human) get an email, I bring up my admin UI (on an instance of the index app I mentioned above). I fill out a form for the new event. I go to a separate page and add a new region. I then go to a third form where I can review and apply the changes. This involves regenerating my map, and I need to update the NGINX configuration in every existing region. There are shortcuts I can use which will update files on each machine and reload the NGINX configuration, but I went that way I would need to ensure that the end result exactly matches the reproducible result that a subsequent `fly deploy` would produce. I don't need that headache, so I'm actually using `fly deploy` which can add tens of seconds to the actual deploy time. I started out running the various commands manually, but that grew old fast. So eventually I invested in creating an admin UI. diff --git a/js/frameworks/meteor.mdx b/js/frameworks/meteor.mdx index 192e91f9c9..94d70e0388 100644 --- a/js/frameworks/meteor.mdx +++ b/js/frameworks/meteor.mdx @@ -208,7 +208,7 @@ Opening https://hello-meteor.fly.dev/ Your browser will be sent to the displayed URL. -## _Session Affinity (aka 'Sticky Sessions')_ {#session-affinity-akasticky-sessions-39} +## _Session Affinity (also known as 'Sticky Sessions')_ {#session-affinity-akasticky-sessions-39} Sticky sessions are a feature of a load balancer that ensures that all requests from a client are routed to the same server. This can be important for Meteor applications depending on the client/server architecture of your app, as it ensures that the client is always connected to the same server, and that any changes made to the server are reflected in the client.