Comment:

With this current change, old challenge links will 404:

- /learn/apis-and-microservices/apis-and-microservices-projects/file-metadata-microservice
+ /learn/back-end-development-and-apis/back-end-development-and-apis-projects/file-metadata-microservice

Mrugesh mentioned the possibility to re-route: https://github.com/freeCodeCamp/client-config/blob/master/serve.json

However, this change can be reverted. CC @ojeytonwilliams

Also, if this re-route is accepted, I will change the links in the READMEs throughout the codebase. By 'I', I mean create an issue, and get help

Mrugesh mentioned the possibility to re-route

@ojeytonwilliams

Just to add if implemented that would still be a temporary patch until we can manage redirection with the webserver (NGINX Configs???) that would sit on top of the static client applications when we move an S3-Minio-NGINX based setup.

All the links in the Guide are to be changed? Please ping if rerouting is a no go, and I will work on it

The idea is no-one (especially backlinks, including links in Guide) should be affected each time we change URLs. There should be systems in place to handle all this.

Re-pinging @ojeytonwilliams for thoughts

Sorry for not getting back to you - I need to manage my notifications better.

As for redirections, I'm heavily in favour of using the existing URLs. My rationale is as follows: every time we create a special case we're making a maintenance headache for our future selves. We also increase the chances that we accidentally break the backlinks whenever we change the infrastructure. They're just one more set of things to potentially forget.

We could handle this via serve, but I don't like that for two reasons. Firstly, we're planning to replace serve somewhat immanently. Secondly, separation of concerns - we already have a reverse proxy (NGINX), so it would be better to let it handle all the redirection logic.

If we're going to do it all, I'd say handle it via NGINX, but I'd prefer to leave the urls as they are.

I'd prefer to leave the urls as they are.

@ojeytonwilliams In that case, we are ok with the file name and title divergence?

we are ok with the file name and title divergence?

Well, unless there's a third option I'm missing, we have to be.

@raisedadead any further thoughts on this?

In that case, we are ok with the file name and title divergence?

That's a hard no.

That would mean someone (particularly some innocent contributor) will end up getting confused.

As I understand this migration needs a form of automatic redirection handling, which we can handle several places, including but not limited to the web server, the reverse proxy, client app etc.

In theory, you want to redirect a user at the first interaction, ideally on the proxy. However, as I see now it the fix needs to be done much deeper than the app server (my previous proposal), i.e within the client app bundle.

Here is a plugin that we should investigate on implementing (alongside its counterpart for picking up the meta): https://www.gatsbyjs.com/plugins/gatsby-redirect-from

That would mean someone (particularly some innocent contributor) will end up getting confused.

They'll get more confused if we mess up a migration down the line and break things. Also, they'll only get confused if they actually read the url which I doubt many people do.

That aside, why would we need to handle this in the client? We really should consolidate this in one place, including moving the current redirects which serve is handling (https://github.com/freeCodeCamp/client-config/blob/master/serve.json). Given that NGINX is the only single place that can handle all of our redirection, I think we should let NGINX handle it.

IMHO, being in the field of ever-evolving tech education, we are in the business of migrations.

We will introduce and remove certifications (and break things) all the time, and we should embrace that change is part of the game (it's never going to be a smooth ride).

This current migration is a need of an SEO indication. The stakeholders most affected by these migrations are currently active users, followed by our currently active contributors.

For example, earlier today, I had someone in the chat confused about "zipline" challenges. We still support a legacy challenge in the codebase and DB because users have claimed certifications in the past. All of it still works. Not many of our currently active users do not know or care about it.

That's how migrations should work. Yes - it's a pain for maintainers, but like it or not, that is the job.

Let me establish the goals real quick:

1. A change in cert names, URLs, etc., meets the signals given to us via the SEO parameters.

   This is already established and should be uniform and avoid all confusion when a non-maintainer looks at them.

2. All secondary needs like backlinks, legacy implementations, etc., should keep working by employing 'smart' systems viz. automatic redirects.

3. Designing such systems (where systems are ideas, concerns, workflows) without being married to any particular technology or tool (that is, avoid bias). We should be working on self-contained systems that can be rearranged for reliability and scale.

The idea is to achieve the goals in the order above and be innovative where we can.

Now coming to the intent, we want to decouple things as gracefully as possible to get close to the "separations of concerns" philosophy.

Here is what I think of it:

1. NGINX is one piece of the puzzle that we have been abusing because it is a swiss army knife. We have been throwing redirect maps and setting headers on it because we can - not because we should.

2. The goal for the proxy layer is to become a pure "transparent" proxy layer in our stack for our load balancing and blue-green release requirements. The job of the transparent proxy is to be dumb to the layers below it.

3. The cert name re-mapping is a logical change in the curriculum. We offer this as a client (here, client means a SPA built with Gatsby). And logic states it should be the concern of the client.

So, where should we handle application logic? Where should we isolate the concerns of the client redirections? Where can we keep a history of the migrations that affected the curriculum that would not confuse future contributors?

I believe it should be in the client & curriculum code.

Yes - intercepting bits at the proxy layer will let us redirect users at will and is even fast and cheap. But not long term. As the usage of older URLs tapers off, the NGINX maps are all looked up on each request due to their static nature. An example of this is 1000+ line guide article URLs. Luckily they are on a subdomain that is not in much use.

Marrying our client app logic to both Gatsby and NGINX leaves us less flexible for future scalability and expansions. It's certainly not being self-contained, at the very least.

By having all logic on the client, we introduce a dynamic redirect only for the user requesting a legacy path, essentially at the same cost of maintenance.

Those are my two cents.

As for moving forward with this PR:

• We should ensure that the slug, file pathname, filename and challenge name have parity.
• Come up with a way that tries to keep one application's logic as close-knit as possible.

I will defer to both of you on this, not against any ideas and whatever is the best approach in your opinion works for me.

A change in cert names, URLs, etc., meets the signals given to us via the SEO parameters.

Just to clarify, you mean the URL should match the content of the page as closely as possible? i.e. it's a bad SEO signal to have the url be /apples if we've changed the content to be about pears.

I wrote a small essay before I realised the source of our disagreement. I see "directing requests to the client" as being a separate concern from the client itself (whose concern is basically handling those requests) and it sounds like you don't.

With that in mind (and because we're trying to avoid over-using NGINX) my preference would be to use serve to handle redirection. In my head that's a sensible separation of concerns. I appreciate that we're not going to use serve forever, but it's trivial to implement (also we can use Cypress to guard against breaking of backlinks).

If we have to handle it inside Gatsby, we can, but it ain't pretty. To the best of my knowledge, we have two okayish options

1. Add <Redirect from="page-a" to="page-b" /> components to 404.tsx
2. Add in <meta http-equiv="Refresh" content="0; url=page-b" /> to page-a, presumably via https://github.com/nsresulta/gatsby-plugin-meta-redirect

The issue with 1. is that we're further abusing the 404 page and returning 404s for those links. 2. might be okay, but the browser support is iffy: https://caniuse.com/mdn-html_elements_meta_http-equiv_refresh it's also generally recommended to use a 301 redirect if you can. Also, the Gatsby plugin didn't work for me, though it should be easy enough to roll our own.

I am mostly in agreement with you here, having known the codebase and its evolution I understand how the nuances and decisions we made in the past could be limiting us here.

As I said in my earlier proposal (not happy, but will work), to go with a config for serve and keep this PR moving while we work on the tooling that will address our requirements better.

Moving the logic into Gatsby's routing would be the most ideal because at the end of the day the client is a SPA. I am not sure how involved it is, but Gatsby has come through a few iterations from when we started, and I have no clue if there is a way to hook into something either at build time or at run time to achieve the desired result.

The app logic related changes we throw in on NGINX should be a last resort type thing, to give us the most flexibility and scalability (if we want to be able to do multi-region, shared deployments, etc.) in future.

As I said in my earlier proposal (not happy, but will work), to go with a config for serve and keep this PR moving while we work on the tooling that will address our requirements better.

I think that's probably the easiest short term solution. Before I do that, I'll write some tests for this, since we want these routes to exist forever and survive us changing our minds/tooling.

Gatsby has come through a few iterations from when we started, and I have no clue if there is a way to hook into something either at build time or at run time to achieve the desired result.

It should be possible to use a build hook to add that meta tag. I can look into creating a plugin that works for our use case.

The app logic related changes we throw in on NGINX should be a last resort type thing, to give us the most flexibility and scalability (if we want to be able to do multi-region, shared deployments, etc.) in future.

Righto. I'm definitely guilty of using NGINX as a first resort, but I see that I'm too keen to reach for it.

Just final clarification: Are we redirecting certification URLs?

That is, should the certSlug change from apis-and-microservices to back-end-development-and-apis?

Just final clarification: Are we redirecting certification URLs?

If we're gonna change some things, we'd best change the rest. If anything's going to be confusing, it'll be inconsistency.

I might be mistaken, but we will need to do some form resetting/purging on Crowdin as well before/after we merge this.

@raisedadead which backlinks do we want to maintain? The certifications, obviously, but what about https://www.freecodecamp.org/learn/front-end-libraries/ and sub-paths and https://www.freecodecamp.org/learn/apis-and-microservices/ and sub-paths?

which backlinks do we want to maintain?

Any and all links that are navigable/shareable at some point need to be preserved. If I am able to share a link in the wild, it needs to be made reachable via its current equivalent.

@raisedadead

The deployment sequence for this will need to be

1. merge feat: redirect to new curriculum paths client-config#4
2. restart tests on this PR
3. deploy to production
4. change the client-config in production

That way all the tests should pass, but the redirects start happening until the new routes exist.

Does that make sense?

Thanks for your pull-request.

We are no longer accepting changes to the non-English versions of files in parts of this codebase. This pull-request seems to change some of those. Please visit our contributing guidelines to learn more about translating freeCodeCamp's resources.

As always, we value all of your contributions.

Happy contributing!

Note: This message was automatically generated by a bot. If you feel this message is in error or would like help resolving it, feel free to reach us in our contributor chat.

Thanks for your pull-request.

We are no longer accepting changes to the non-English versions of files in parts of this codebase. This pull-request seems to change some of those. Please visit our contributing guidelines to learn more about translating freeCodeCamp's resources.

As always, we value all of your contributions.

Happy contributing!

Note: This message was automatically generated by a bot. If you feel this message is in error or would like help resolving it, feel free to reach us in our contributor chat.