Limits of a Headless CMS?

Jamees Bedford - Feb 18 '19 - - Dev Community

Hey Dev.to!

Long story short, I am a front-end developer working on a full-stack team management application. The app is built in Node.js and MySQL, and allows team leaders to invite their team members, where they will take an assessment where they can then be graded and organised accordingly within a company.

Its being BETA launched in a few months, which I have got it stable for, but moving forward I fear for the expandability of the application in its current state.

I am tempted to start from scratch, or at least rebuild certain aspects of the app over again.

The idea is to have team management functionality but to bring in data from third-party HR applications through their APIs and then sort the user data within the application. I would like to at some point integrate some sort of in-app training functionality (videos/materials etc) as well as build a (light) testing section where users can solve problems and get a higher rating on their account.

My initial instinct was to go straight in with a Node.js/React stack, however, my skill sets lie primarily with the front-end and I fear my lack of back-end knowledge will let me down with the growing complexity of the application.

A Headless CMS like Sanity or Strapi seems like a perfect solution for those users who actually visit the application and sign up, but I am not sure just how well these are suited to allowing more complex functionality. I guess if everything was coming through a GraphQL layer then the headless CMS could be performing in parallel to data pulled from separate third party APIs. Or are they just suited to the standard website/blog/e-commerce use case I see in all the examples? Would this be a good solution for my application, or am I just opening up new problems?

Extra question:
How would you structure an application like this?

TLDR:
Is a headless CMS a good option for a complex application? If not why?

. . . . . . . . . . . . . . . . .
Terabox Video Player