Best way to maintain multiple similar apps?

[djuszko]

I'm building multiple apps which will be 80%+ the same, but am struggling to find a good way to structure these projects.

I'll use the example of books/movies/songs. I have built buybooks.com, and now want to begin working on buymovies.com and in the future buysongs.com. The structure of the sites is the same, as is their general purpose. They will have different styling/themes/images, and much of the data may be different (ie movies/books do not belong to an album but songs do), and so some customization is required. However, the majority of it will be the same.

What is the best way to structure these projects so that a change to a common component affects all projects?

My current idea is to create a monorepo with a structure like this:

│──common
│  │─components
│  └─utils
│──buybooks
│  │─package.json?
│  └─pages
│──buymovies
│  │─package.json?
│  └─pages
└──buysongs
│  │─package.json?
│  └─pages
└─package.json?

I moved my components directory out of buybooks and into common so that future projects can re-use those same components, and I could make them more generic when needed in the future.

Some issues with this setup:

• I immediately ran into the issue of the files in the common folder not having a proper loader. I assume this is because they are located outside of the nextjs project that is buybooks. Should the root folder or common folder be set up as a next project? Do I just add a .babelrc file somewhere?
• This would allow me to reuse components across projects, but if I wanted to change something in one of the pages folders in a project, I would have to duplicate those changes once for each project. Is there a good way to maintain reusability for cases like this?
• Similarly, I use an Express server.js file that runs Next. Is there a good way to maintain changes across all projects?

Another potential option would be using a git subtree or submodule. Is there any merit to these approaches?

[djuszko]

Here is what I've come up with:

• I set up the monorepo using Yarn workspaces. I'm having some issues with buybooks.com properly transpiling my components from common/components, but I think I'm on the right track. It looks like Next.js was supposed to officially have support for this, but in the end dropped it? I'm looking into next-transpile-modules to solve this issue.
• In order to make pages components reusable, the idea is to do something like this:

// CURRENT:
// pages/itemDetail.js
import { example } from 'example-library'

function ItemDetail(props) {
  return (
    <h1>Item Details</h1>
    <ul>
      ...
    </ul>
  )
}
ItemDetail.getInitialProps = async ctx => {
  ...
  return { exampleProps }
}
export default ItemDetail



// NEW:
// pages/itemDetail.js
import { ItemDetailPage, itemDetailGetInitialProps } from 'common/pages'

function ItemDetail(props) {
  <ItemDetailPage {...props} />
}

ItemDetail.getInitialProps = async ctx => itemDetailGetInitialProps
export default ItemDetail

My issue was that I wasn't sure how to make pages components reusable, but the (simple, in hindsight) proposed solution is to just extract all of the component into yet another component, and then have the pages only render that. That way, any changes to the ItemDetail pages for all sites can be made by modifying the ItemDetailPage function, or it's corresponding itemDetailGetInitialProps function. Presumably, server.js can be handled in a similar way.

... I think. I'm afraid that I may be missing something, and I'm afraid of going far down this route before realizing some grave mistake or problem with this way of thinking. What do you guys think? Is there a better way to do this?

[Vadorequest]

@djuszko Take a look at https://github.com/UnlyEd/next-right-now

What you want to to, we've named it "Multi Single Tenancy" and I wrote about it at vercel/vercel#3547 (comment)

It doesn't support code differences between tenants (at this time), meaning all tenants share the exact same source source code, but it supports fetching/using/displaying different data using the same code base. So, all the differences between tenants lies in the data themselves.

[djuszko]

Cool project! Thank you for sharing.

I'm not sure it's the solution for me, however. The code bases will be similar but they can't be identical. There will need to be some differences, despite the sites sharing so much code. Also, my project uses Express and Nginx for deployment, so NRN may not be right for that reason as well.

[Vadorequest]

Sounds legit!

I believe using prefixed/suffixed files could be a solution for a per-tenant source code customisation, while reusing the common source code. I'm not sure about how to make work such dynamic imports (technically speaking), but I believe it's feasible.

As for Nginx/Express, I personally prefer Vercel which is much easier to manage and less time consuming (less costly too, for me).
NRN is thoroughly documented and even if you can't use it as a boilerplate, dont hesitate to take a look, it may inspire you 😉

[Vadorequest]

@djuszko Take a look at #13843

I'm not 100% sure it'll solve your issue, but it might help achieve something similar. (especially if MDX can be stored on a DB, then your file structure may stay the same for all customers, and yet customise each page based on the customer's MDX content)

[djuszko]

Thanks for thinking of me! That's actually pretty cool. Don't know if it will work for me but I'll consider it. Might need to get a little creative!