Replace flex-server by hosting recipe info on GitHub

[nicolas-grekas]

This PR replaces the flex.symfony.com endpoint that flex currently uses by a new endpoint made of static JSONs hosted on GitHub.

Said JSONs are here:
https://github.com/symfony/recipes/tree/flex/main

And are generated by GHA:
https://github.com/symfony/recipes/blob/master/.github/workflows/flex-endpoint.yml

With the help of this tool:
https://github.com/symfony-tools/recipes-checker

The target is to retire flex.symfony.com at some point in the future and free us from maintaining and hosting it.

As a nice side effect, this should make it easier for ppl to host their own flex endpoint overlay.

It should also enable contributions for the community to innovate at the Flex API layer.

The default endpoints can be changed by setting the extra.symfony.endpoint entry in the root composer.json file. The special flex://defaults endpoint can be used in that list to reference the default endpoints.

On top of that, the SYMFONY_ENDPOINT env var can be defined to a single endpoint. This endpoint will be used on top of (with higher priority than) the default endpoints of the app.

[fabpot]

... and that removes a SPoF, which is always nice :)

[herzmut]

While I always appreciate the technological economization of any ecosystem by removing weak technological dependencies, such as one operated by a company, and moving to community-accepted conventions, such as foundations or any other kind of common place,

how is this PR removing a single point of failure if all it does is replacing flex.symfony.com with GitHub as the source?

[fabpot]

SPoF == servers as you mention, but it's also about the number of people maintaining the server/code.

[icanhazstring]

Does this make sense to have something similar to composer repositories?

Where I can add a certain in-house hosted flex recipe server which holds proprietary recipes before looking into the default one?

Or is this change exactly this?
Couldn't figure out using the source.

[nicolas-grekas]

@icanhazstring yep, that's what the code does already: define extra.symfony.endpoint in the root composer.json to the list of endpoints you want for your app (you'll have to duplicate the default endpoints, but they're stable so that should be OK use flex://defaults in that list if wanted)

[icanhazstring]

Nice. Good solution. Thank you 💪

[alexander-schranz]

@nicolas-grekas would it make sense for backwards compatibility to rename the current main and master branches to 1.x so if there is in future a 2.x release which maybe use another .json format which will not break?

[nicolas-grekas]

We're talking about the branch name of recipes. There will be no v2 as there is no v1 either :)

[wouterj]

What @alexander-schranz means I think is: what if we refactor the JSON api in the future? (e.g. another json format to support cool new things)

If we don't version the URL, it means we force all apps to directly upgrade to the latest Flex version or to make all JSON format changes backwards compatible.

[nicolas-grekas]

the version would then belong to what's inside the json, not to the URL
I think all is future proof already:

• different format of recipes (eg php-dsl) = new endpoint, eg flex/main replaced by flex/main-php
• new API payloads = new keys in index.json, possibly with a version, but only the day we actually need it imho

[alexander-schranz]

If you are sure there will be no issue with ref to main/master then its good :)

[medwards-cyc]

If learning this wasn't confusing enough, you now take away the server that made sense? - nice :(

[wouterj]

✔️ The service's usage didn't change
✔️ The service now allows privately hosted Flex servers, for internal recipes
✔️ The free service doesn't cost hosting money anymore
✔️ The service no longer relies on a single server, but uses the massive HA architecture of GitHub
😐 If you want to know internals, you'll have to relearn the downloading part of Symfony Flex

I can fully understand why this change was made :)