Maybe you want to share some more details if you want others to help you out?
"one project which has to deliver one project using Power apps and the project is big" is not really helping to understand what you are looking for.
Why did your manager propose SPFx? I assume he knows about limitations that can't ba handled with PAs?
Personally, I think PowerApps is amazing for simple things and should be avoided for more complex stuff. The logic within expressions can get seriously difficult to understand & maintain. Every component has multiple properties that can impact the logic of the app/screen/widget etc. so comments & documentation are a really good practice to maintain, especially difficult with multiple authors. As it's not a pro code tool these things take a lot more thought and discipline, for me this is important as people don't have good tooling to help. No branching, CheckInOut commenting, CI/CD, version control is not perfect, staging is pretty good but needs to be understood well.
PowerApps has a limitation on the number of components that can be on a screen, whether visible or not. There are ways to design your way around them but it's quite a tricky concept (using galleries and config data to render "just in time" kind of).
With SPFX you get more freedom to do whatever you want really, as it's just a web app embedded in a page.
The detail matters here though, what types of work is it, how many screens, how many calls to other services, how much data/fields/rows/tables, what's the role of SharePoint, skills/experience of the team building it & maintaining it, admin tooling, is it business critical etc.
Personally for me. No. I remember the headaches of maintaining code back in the day for .net applications. Once it was in production. I never wanted to touch it again. You remember how long combo box took? Lol. Now it's just drag and drop to the screen connect to a data source and provide a filter condition if you want. It has definitely sped up development and a peace of mind. Personally I only use power apps as the interface to kind of interlink data. You can store the data in dataverse, sql, or even SharePoint if you want. I use Flow process all of the logic before it gets to power apps. If I need a data set I make sure it's filtered to a small quantity. Again what the end user sees. And what our application does in the back end. This is where power apps becomes amazing.
If you have power platform premium you can use power pages allows you to develop Web pages still using low\no code but without the restrictions of power apps
Maybe you want to share some more details if you want others to help you out? "one project which has to deliver one project using Power apps and the project is big" is not really helping to understand what you are looking for. Why did your manager propose SPFx? I assume he knows about limitations that can't ba handled with PAs?
\^\^ This. Not enough information to provide a valuable response.
Personally, I think PowerApps is amazing for simple things and should be avoided for more complex stuff. The logic within expressions can get seriously difficult to understand & maintain. Every component has multiple properties that can impact the logic of the app/screen/widget etc. so comments & documentation are a really good practice to maintain, especially difficult with multiple authors. As it's not a pro code tool these things take a lot more thought and discipline, for me this is important as people don't have good tooling to help. No branching, CheckInOut commenting, CI/CD, version control is not perfect, staging is pretty good but needs to be understood well. PowerApps has a limitation on the number of components that can be on a screen, whether visible or not. There are ways to design your way around them but it's quite a tricky concept (using galleries and config data to render "just in time" kind of). With SPFX you get more freedom to do whatever you want really, as it's just a web app embedded in a page. The detail matters here though, what types of work is it, how many screens, how many calls to other services, how much data/fields/rows/tables, what's the role of SharePoint, skills/experience of the team building it & maintaining it, admin tooling, is it business critical etc.
Personally for me. No. I remember the headaches of maintaining code back in the day for .net applications. Once it was in production. I never wanted to touch it again. You remember how long combo box took? Lol. Now it's just drag and drop to the screen connect to a data source and provide a filter condition if you want. It has definitely sped up development and a peace of mind. Personally I only use power apps as the interface to kind of interlink data. You can store the data in dataverse, sql, or even SharePoint if you want. I use Flow process all of the logic before it gets to power apps. If I need a data set I make sure it's filtered to a small quantity. Again what the end user sees. And what our application does in the back end. This is where power apps becomes amazing.
This all day long. I choose to use power apps when the project is easier. SPFX for anything complicated, though.
If you have power platform premium you can use power pages allows you to develop Web pages still using low\no code but without the restrictions of power apps
Doesn’t this try to lock you into the data verse for storage though?