headless or codebase for clerk.dev flexibility?

Hi there! I’m setting up a new create-plasmic-app instance and need to decide between plasmicLoader and codegen. I’d love to use the former, but I’m not sure what my usecase demands.

I’m admittedly very new to this kind of dev - and am really enjoying it. So pardon any obvious questions… :slight_smile:

I intend to use plasmic for both the front end site/marketing pages, as well as for a customer portal.

I want to use clerk for the auth, and to do so:

  1. I must wrap that portal section in their component (so access to headers).
  2. I must make sure those pages are dynmically rendered.

Clerk says anything wrapped in its component will be opted into dynamic rendering - but I know Plasmic uses this when using create-plasmic-app.

So my questions:

  1. to use plasmic for both the main site and the portal, would I create two separate plasmic projects/apps?

  2. Will plasmicloader allow me to wrap the portal pages in the clerk.dev component?

Really appreciate the help!
MItch

Hi and welcome!

Yes I typically like to organize things so that the marketing website is in a separate project from the application. If you have any common components / tokens/assets to reuse across the two, you can extract those into a common design system project that is then imported into each of the downstream projects.

You can use the headless API even with custom auth, and I would generally recommend trying hard to stick with headless API given that codegen is significantly more complex and manual.

To integrate with clerk dev, you can follow the same general approach described here for custom off integration, and we have a complete repo example with Supabase auth here

https://docs.plasmic.app/learn/auth-integration/#custom-auth-provider

And for your portal, let me know if you are interested in this limited priority feedback program (): Plasmic pilot program applications - Google Docs

Please let me know if that helps!

It did indeed. And modeling the plasmic-supabase-auth repo. I think the _app.js piece is what was missing from my understanding of how next.js works - and how to wrap something like clerk.

Thanks again, Yang!