Payload and NextJS - Same or separate repo / environment ?

sssspraylast year

12

• 

  terraxellast year

  I believe it depends as you said. It depends on your application, maybe, but also on your vision, for sure. My own vision of it is that it should be separated. I see headless as a content provider, that's it. I want to have a rest api and a graphql api that provides me the data to build pages, of course, but also different types of contents. I like it to be independent.

  
  
  

  (However, I would like to clarify that I'm no pro of payloadcms 🙂 )

• 

  sssspraylast year

  @Terraxel Yes, I also tend to think it's best to separate it, but as I've seen other including them, and as it's also explained in the doc, I was thinking that maybe there are some benefits to keeping them together. Thanks for the reply !

• 

  christopher.nowlanlast year

  @chuck I've built a few websites with PayloadCMS and Nextjs and I tend to keep the repository seperate. I host the payload CMS on one server and Nextjs part on vercel

• 

  clement6396last year

  I've personally chosen to separate the two projects again, as I think that integrating Payload into Nextjs requires a lot more maintenance during version upgrades.

  
  

  
  

  But I use a monorepo to share types

• 

  imcorfitzlast year

  On that note - if you don't mind me asking, despite not being 100% related to the question. Have you upgraded to Payload 2.0? We are running same setup using a monorepo. And whenever we trigger

  generate:types

  it automatically copies it to our Next app.

  
  

  "generate:types": "turbo run generate:types && cp apps/cms/src/payload-types.ts apps/web/payload-types.ts"

  
  

  However, since Payload 2.0 the

  generate:types

  script also adds a module declaration to the types file, and since my Next.js app doesn't have payload as a dependency, it throws an error now, and requires me to manually go in and remove that part:

  
  

  declare module 'payload' {
    export interface GeneratedTypes {
      collections: {
        // Collections
      }
      globals: {
        // Globals
      }
    }
  }

  
  

  If you have faced similar - how do you combat it? Adding payload as a dependency to Next.js? Manually removing it? Adding a quick bin script to execute the removing automatically after generating the types? I am curious. 🤔

• 

  clement6396last year

  I have no problem with type generation

  
  

  
  

  I don't copy the payload-type file but import it from Next

  
  

  
  

  
• 

  terraxellast year

  Wouldn't it be easier to use a codegen for requests instead of generating types and sharing them ?

  
  

  
  

  graphql-codegen for graphql api, and nswag for http api for example

• 

  imcorfitzlast year

  Ah see - proper use of monorepo. Clever lad you are.

  
  

  
  

  I tried using graphQL-codegen. I found it a bit - too much? I didn't feel like the hassle was worth the result. You might argue that the type-safety is better, but I still found it to overly complicate my codebase. It didn't feel as elegant. Might have done it wrong, but I didn't fancy it. Full disclaimer - this is a personal opinion.

• 

  clement6396last year

  I don't feel I need an extra layer, a simple fetch with my type as a parameter is more than enough to type my entire project.

• 

  abernierlast year

  Usecase: a project with a

  Pages

  collection. Each page is just a list of "blocks" user-contributed. Each block of data, rendered by a React component in a Next app.

  
  
  

  In this usecase, it made a lot of sense to me to be able to collocate my block-definition along the React component that will render it.

  
  
  

  a bit like collocating graphql fragment with RC pattern

• 

  jimpexlast year

  For future reference for anyone that is interested here is a blog post payload released that talks about this topic

  https://payloadcms.com/blog/the-ultimate-guide-to-using-nextjs-with-payload
• 

  abernierlast year

  awesome article