Page MenuHomePhabricator

[e.cash] Get blog posts
ClosedPublic

Authored by johnkuney on Jun 22 2023, 21:48.

Details

Reviewers
bytesofman
Group Reviewers
Restricted Project
Commits
rABC840f22843295: [e.cash] Get blog posts
Summary

Adding the functions and tests that will be used to fetch the blog posts from the new strapi cms
Strapi has a response limit for how many entries it can return at once. It can be upped to 100 which
would cover our existing 81 posts, but obviously that wont work for long so idea here is

get the amount of pages there are from the metadata in the response
loop through that amount and fetch each page of posts
combine the responses in one array that will be returned to getStaticProps in a later diff

Test Plan

review the functions and tests
npm run test

Diff Detail

Repository
rABC Bitcoin ABC
Branch
ecash-fetch-posts
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 24138
Build 47886: Build Diff
Build 47885: arc lint + arc unit

Event Timeline

bytesofman added a subscriber: bytesofman.

Why do we want to fetch every single blog post?

Seems like paginated return would be useful to load only enough blog posts for the current page.

As the blog grows, quickly impractical to have an API loading hundreds of posts on page load when the user can only read one at a time.

web/e.cash/data/blog.js
5–10
20

put return response.meta.pagination.pageCount; inside the try {} section and add a unit test to show that an error is thrown if the API returns data that is not of this exact expected shape, for example an empty object {}

35
39
This revision now requires changes to proceed.Jun 22 2023, 23:55

Why do we want to fetch every single blog post?

Seems like paginated return would be useful to load only enough blog posts for the current page.

As the blog grows, quickly impractical to have an API loading hundreds of posts on page load when the user can only read one at a time.

So I was thinking ahead of myself for all of the individual paths and pages we need to resolve. Basically any old post slug needs to resolve if navigated to directly...but we wont have that data if only the first 25 posts have been fetched...
But I agree eventually it would be unwieldy, to be fair not for several years at least ha (also curious how webflow does it as they list every post on the blog page with no lazy loading afaict)
Also keep in mind this will only run at build time so users wont be waiting on this data
But anyway thats a separate diff anyway and there are others ways to do it where for the individual post pages the data is fetched by slug and rendered at request.
I think in general theres more than one way to do it obviously, so need to consider what we want to optimize. Speed and SEO will be on our side if fetch them all, but may eventually become too large (although 100per page will limit to only like another page request every two years assuming same rate of blogs)

Also keep in mind this will only run at build time so users wont be waiting on this data

oh ok, then this approach makes sense.

add data shape test and improve for loop variable

bytesofman added inline comments.
web/e.cash/data/blog.js
17 ↗(On Diff #41000)
21 ↗(On Diff #41000)

no need to keep this after the catch

This revision now requires changes to proceed.Jun 26 2023, 17:26

Seems like we don't get a lot of value hosting all the blog posts on a separate server if we still need to rebuild and redeploy the app every time we publish a new blog post.

Why are we getting all of the blog posts at build time and not just loading / rendering the blog page dynamically based on what the server is providing?

So the main value of hosting somewhere else is so the blog authors have a user friendly CMS to make the posts

As for the build time fetching the main benefits are

  • Much faster load times
  • SEO performance (static prebuilt pages are indexable)

We do have to build the site for every new post, but those aren't super frequent (like 2 a month?) And there are ways to automate it with strapi webhooks

Overall I'm going this route as its recommended specifically for this use case, and will produce a fast site https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation#when-should-i-use-static-generation

Easy to switch to serverside props instead if there are reason we dont want to do it this way

This revision is now accepted and ready to land.Jun 26 2023, 19:56
This revision was automatically updated to reflect the committed changes.