You would better off with https://homebrewery.naturalcrit.com/download/:id .. that returns the raw source with no UI or fiddling (unlike /share/:id or even /source/:id)

I had a bit of a poke at the library app, it appears that it's just scraping the brew's metadata.

Homebrewery doesn't force updates to brews in storage, so older brews may not have every metadata option in the code-fenced metadata block in the brew text - for example, pageCount is a relatively new metadata feature, and may not exist on every brew. Similarly, the codefenced metadata block in the brew text (which is visible via the /download/:id endpoint) will not exist on older brews (that is, brews that have not been edited or updated since the change went live).

A better API endpoint would be for Homebrewery to implement a /metadata/:id endpoint which returns a JSON object with only the brew metadata - title, authors, version, pageCount, description, thumbnail image URL, publication status, and so on.

However, something to consider for the library app itself is that Homebrewery is completely open source and free, and anyone can run it locally on just about any OS (Windows, macOS, Ubuntu, Debian, FreeBSD, RaspBian, or anything that will run a Docker image), so there is no guarantee that a user's Homebrewery document will always exist at https://homebrewery.naturalcrit.com/share/:id.

Thanks a lot for the helping me with this and even checking out my code, I will check out the /download/:id and /source/:id endpoints, I did not know they were a thing. I might be worth it to write a quick little wiki entry with a list of the endpoints and a one sentence explanation of what they do because they seem to be quite scattered in the code so its easy to miss one.

It's also good that you told me that older brews might lack some data, I only tested it with a handful of documents so I never ran into problems but others might. I'll change my code to account for that. A /metadata/:id endpoint that always has all the metadata fields, even if some of them are empty, would be perfect.

As for homebrewery deployments that are not on the https://homebrewery.naturalcrit.com domain, would there be an easy way to verify if any given URL is a valid homebrewery deployment? I guess not because the source code of the self deployed version could have been changed so any check I would do might not hold true any more so I think I will keep the domain check by default for now so that the vast majority of users that use the official deployment will have the convenience of getting a warning if they make a typo or formatting mistake and add a checkbox that disables the domain check for self-hosted users that know what they are doing.

@DSPaul Is that project still being worked on? Can we get an update? Should we close this issue if its not going to be worked on?

Yes I am still actively working on the project, and still using the scraping method as I described above. It has proven reliable enough as it hasn't broken in the past year. I would still like to see this implemented so I wouldn't close the issue but given that there is a working workaround, you can treat this as very low priority.

As for homebrewery deployments that are not on the https://homebrewery.naturalcrit.com domain, would there be an easy way to verify if any given URL is a valid homebrewery deployment? I guess not because the source code of the self deployed version could have been changed so any check I would do might not hold true any more so I think I will keep the domain check by default for now so that the vast majority of users that use the official deployment will have the convenience of getting a warning if they make a typo or formatting mistake and add a checkbox that disables the domain check for self-hosted users that know what they are doing.

I am confused as to what do you want in relation to PR deployments, those are temporary domains to test stuff, why would you or any user of your app want to access them?

From what i gather, you want a /metadata/:id (or other name) endpoint which should return a JSON object with only the brew metadata - title, authors, version, pageCount, description, thumbnail image URL, publication status, and so on. Is that correct?

Also, thanks for the very fast reply.

Working example

Astonished as to how simple that turned out to be, i'm more the CSS guy

Awesome, that is exactly what I wanted! Thanks for implementing this. You can go ahead and merge the PR and close this issue as far als I'm concerned.

Ps.
You can forget what I said about self hosted instances of homebrewery, it was pretty far fetched and irrelevant, I was thinking at the time that some people might be hosting their own fork, mastodon style but that is clearly not the case, everyone just uses the official instance.

Sorry this took this long, could you share a link to the app? I'm interested.

Stealing their thunder: https://www.compassapp.info/