can someone make a nextjs app that takes our public github discussions and makes SEO-friendly read-only replica?
we want to run cal. com/community and when you want to comment, you get linked to github
โ Peer Richelsen -- oss/acc (@peer_rich) June 24, 2024
good to know
maybe the approach to add commentary to it (by gpt-summary of the discussion and maybe removing non-answers) is enough to not be considered duplicate?
โ Peer Richelsen -- oss/acc (@peer_rich) June 24, 2024
Exciting.
The coolest part is that with ISR you can make it very fast, control exactly how often you want to revalidate the caches, and prevent rate limits on the upstream API.
For example, if a react.dev project has a link to /help, it normally will route to react.dev/help. However, in our case, it should route to piri.dev/ko/react/help. How can we snatch the request and return the correct stuffs?
The request itself will be sent from the browser, so we can't touch that part. i.e., this inner link replacement process should be stateless.
We can't look for "oh, this guy is at this directory... so if they requested /help, it'll mean this website."
All information should be corrected and valid at the moment of HTML response.
Modifying the MDX itself?
Too complicated, too many weak links
When returning the HTML from the server, run DOM to find and replace inner links?
Maybe this could work
Then we need to completely abandon SPA
Just don't fix it?
Not a consideration, it will virtually break every single link
The flute folder stores all of the raw projects, using git submodules. For example, the React project documentation will live under flute/react. There will be many documentations, such as flute/react-native, flute/flutter, flute/docusaurus, etc.
Then, there is a lang.ts file that governs the languages. It will export a JSON, with language key and the language name.
The final output will be localized into the piri folder. For example, piri/ko/react will store all of the Korean translation of the React project. piri/ja/react will store the Japanese version of the React project. The slug after the language code will be the same as the slug after the flute folder in the source.
piri.dev shows the initial project page
piri.dev/ko will show all the lists of the projects that are available in Korean
piri.dev/ko/react will show the Korean-translated index.html of the React documentation
piri.dev/ko/react/errors will show the Korean-translated react.dev/errors content of the React documentation.
can someone make a nextjs app that takes our public github discussions and makes SEO-friendly read-only replica?
we want to run cal. com/community and when you want to comment, you get linked to github
โ Peer Richelsen -- oss/acc (@peer_rich) June 24, 2024
good to know
maybe the approach to add commentary to it (by gpt-summary of the discussion and maybe removing non-answers) is enough to not be considered duplicate?
โ Peer Richelsen -- oss/acc (@peer_rich) June 24, 2024
Exciting.
The coolest part is that with ISR you can make it very fast, control exactly how often you want to revalidate the caches, and prevent rate limits on the upstream API.
For example, if a react.dev project has a link to /help, it normally will route to react.dev/help. However, in our case, it should route to piri.dev/ko/react/help. How can we snatch the request and return the correct stuffs?
The request itself will be sent from the browser, so we can't touch that part. i.e., this inner link replacement process should be stateless.
We can't look for "oh, this guy is at this directory... so if they requested /help, it'll mean this website."
All information should be corrected and valid at the moment of HTML response.
Modifying the MDX itself?
Too complicated, too many weak links
When returning the HTML from the server, run DOM to find and replace inner links?
Maybe this could work
Then we need to completely abandon SPA
Just don't fix it?
Not a consideration, it will virtually break every single link
The flute folder stores all of the raw projects, using git submodules. For example, the React project documentation will live under flute/react. There will be many documentations, such as flute/react-native, flute/flutter, flute/docusaurus, etc.
Then, there is a lang.ts file that governs the languages. It will export a JSON, with language key and the language name.
The final output will be localized into the piri folder. For example, piri/ko/react will store all of the Korean translation of the React project. piri/ja/react will store the Japanese version of the React project. The slug after the language code will be the same as the slug after the flute folder in the source.
piri.dev shows the initial project page
piri.dev/ko will show all the lists of the projects that are available in Korean
piri.dev/ko/react will show the Korean-translated index.html of the React documentation
piri.dev/ko/react/errors will show the Korean-translated react.dev/errors content of the React documentation.