Find by product name (with fuzzy matching)

[jgbolger]

I think it would be a useful addition if the API supported the ability to find a product by name with fuzzy name matching. This would essentially allow me to find the end-of-life date for "Windows Server 2016", or "Microsoft Windows Server 2016", or "Windows Server 2016 (R2)" etc. The reason is that there are many tools used to collect such data and all use different naming standards. This could potentially be implemented via regex matching. I'd be happy to contribute a PR if there is interest in this. I can build this into my own tooling but would rather contribute it here if useful.

[adriens]

On the user-end, this would make it possible to build nice looking and useful autocomplete forms 👍

[marcwrobel]

Hi @jgbolger, that would be a nice addition but that's unfortunately not possible for the time being.

The reason is technical: endoflife.date, including its API, is just a static site. This means all files are generated when the site is built and then those files are just served by the server. So no additional processing, such as a fuzzy search, is possible at request time.

On the https://endoflife.date/ website, the search feature is implemented in javascript using https://lunrjs.com/ (if I recall correctly). So the search is actually made by the browser, not the server. On API side no such thing can be implemented, so unfortunately you will have to build this into your own tooling.

@captn3m0 do you confirm there is no short-term or medium-term plan to build an application that could be used to implement this fuzzy-search feature?

[marcwrobel]

You're welcome.

Something to consider alternatively would be to include the regex for name matching in the data model. That way you could keep all the data together, rather than having client APIs augmenting each product with the regex to perform fuzzy matching.

I am interested by the alternative but I do not understand. Could you elaborate with an example ?

[adriens]

we can look at publishing regular dumps

I have in my plans to load the whole endoflife.date into Neo4J... but also in OpenSearch 😸 ... BTW,
Also, we could get inspiration from OpenFoodFacts data exports who deliver MongoDB dump, JSONL data export, CSV Data Export, and RDF Data Export.

I'm actually a little break for holidays, but I should focus on the Neo4J as soon as the new API will be available 🚀 🤩 I'll probably use internal resources to achieve some animation around endoflide.date in 2023 ✨

[jgbolger]

You're welcome.

Something to consider alternatively would be to include the regex for name matching in the data model. That way you could keep all the data together, rather than having client APIs augmenting each product with the regex to perform fuzzy matching.

I am interested by the alternative but I do not understand. Could you elaborate with an example ?

Sure. For example, here is what the API response would look like for Windows Server 2016, with the addition of a new nameRegEx column:

{
  "buildID": "10.0.14393",
  "releaseDate": "2016-10-15",
  "support": "2022-01-11",
  "eol": "2027-01-12",
  "extendedSupport": false,
  "lts": false,
  "nameRegEx": "^(Microsoft |MS )?Windows Server 2016(( 32 bit)|( 64 bit))?$"
}

Please ignore the actual basic regex used! But the idea is that we could then define patterns for identifying the product and cycle. The calling client could then apply those regular expressions locally, without needing to store them separate to your API.

One other attribute that might also be useful would be a product category. For example, I might want to retrieve or group all products with a category of "os" or "database"

[marcwrobel]

That seems a good idea, I will keep it in the back of my mind.

One other attribute that might also be useful would be a product category. For example, I might want to retrieve or group all products with a category of "os" or "database"

Such categories already exist. It will be augmented with tags in a near future (#2225), and API is currently being rewritten to better support this (#2080).

[jgbolger]

Great, I look forward to v1 of the API. Thanks for the quick response