added the sync request to a package script and updated readme to help with onboarding

[dealvz]

The main motivation for this ticket was essentially to lower onboarding friction and improve our readme. It's minor but its nice to have consistency when we're setting up the project initially. We have nice package.json scripts for seeding, so a script to sync cms content locally I think plays well with the existing process (we can also expand on it to sync specific content later).

That being said, this minor ticket did bring my attention to what may or may not be an issue. If you take a look at the contentfulSync.ts script, its a basic call to our sync endpoint (see content.controller.ts). I dug a bit and I can't seem to find any instances of the endpoint being called elsewhere in the code, either in the webapp or the api, and I don't think it'd be called by a contentful webhook would it?
So the main question I have is:
Is this endpoint being called from anywhere else?

This seems important because it appears to be an unprotected endpoint, open to the public. I saw our global auth guard but I believe this endpoint bypasses it with PublicAccess, potentially allowing for anyone to call it, which may write to production and cause some issues. Some bad things that this can cause:

• bad actor decides to hit the endpoint en masse, ddos us and cause an outage or delay other valid requests
• contentful rate limits could kick in and cause other content being served to error out
• make our contentful bill more expensive (?)

That all being said, if this endpoint is being used somewhere for something I'm simply unaware of, please let me know and perhaps we can place it behind some protection (role, w.e). If that protection exists and I missed it, let me know and my bad.

If the endpoint is not being used, I propose we remove it from this controller and I'll happily update this PR to move the logic into the new seed/contentfulSync.ts script so its not exposed to the public.

---

Note

Adds an npm script and seed file to sync Contentful data, with README instructions for setup and usage.

• Scripts:
  • Add npm script sync:cms to run seed/contentfulSync.ts.
  • New seed/contentfulSync.ts invokes GET http://localhost:3000/v1/content/sync and reports created/updated/deleted counts.
• Docs:
  • README: add Content Sync section with command usage, required Contentful env vars, tables populated (content, blog_article_meta), overview of synced content types, and idempotency note.

^{Written by Cursor Bugbot for commit 84111f8. Configure here.}

[cursor]

Comment @cursor review or bugbot run to trigger another review on this PR

[RavenHursT]

If this works, then could we not just delete https://github.com/thegoodparty/gp-api/blob/develop/src/content/content.controller.ts#L81-L92 entirely?

@tomeralmog @tomer-tgp I don't think we're calling it from anywhere other than manually from our local, right?

We can't remove that endpoint rn.. it's called by the Contentful webhook.

[RavenHursT]

This is cool.

But, there's a dev workflow when working on DB models, where we want to run npm run migrate:reset over and over again. This'll severely slow down that flow if it runs w/ ever migrate.

Can we do something similar to the npm run seed:* tasks that we have where we can pass prisma a command line arg to disable this seed if we so choose? 🤔

gp-api/package.json

Lines 22 to 23 in d63951d

	"seed:all": "npx prisma db seed -- --type all",
	"seed:csv": "npx prisma db seed -- --type csv",