There are a number of architectural issues that call for a ground-up rewrite of the current code. There are certainly pieces we might keep, but at the moment, nothing is sacred. AC is still a relatively small codebase with only two production deployments (FAIR and TYPO3), and should be agile enough to make this change without disruption.
First, AC as currently constituted is a very much a database-centric design, but 90% of what we do is storing and serving static JSON documents, plus minor transforms like URL rewriting which involves no relational structure at all. While search could and probably should continue using postgres, there's no reason to be involving the db at all to serve the JSON blobs. AC is effectively a document database, not a relational one: just about the only association that's meaningful is packages to authors, and we aren't even doing much to manage authors. Moreover, the documents are static, where any change to the content results in a new ID (in fact, no change often still results in a new id, but that's a different issue). The abstraction we should be targeting is the filesystem, adding DB indexing on top where needed.
I'm not quite as negative on Laravel these days as I have been in the past, mostly due to IDE tooling catching up. I still have a laundry list of complaints with Laravel (including needing that IDE tooling to begin with) but I don't need to rehash them here. The main issue is that Laravel is essentially a monolith, most of which we're not even using, and should we move away from a DB-centric design, Laravel has even less reason to be there. We initially chose Laravel because we had a talent pool with Laravel experience, but now that that's no longer the case, there's no reason to keep it in place, and the existing codebase isn't big enough to call Laravel a sunk cost. Better to rip the band-aid off early.
I'm going to begin some exploratory porting work this week, but I'm inviting the new contributors from TYPO3 to discuss both the design and implementation, so nothing will be finalized until we've gotten input from them.
There are a number of architectural issues that call for a ground-up rewrite of the current code. There are certainly pieces we might keep, but at the moment, nothing is sacred. AC is still a relatively small codebase with only two production deployments (FAIR and TYPO3), and should be agile enough to make this change without disruption.
First, AC as currently constituted is a very much a database-centric design, but 90% of what we do is storing and serving static JSON documents, plus minor transforms like URL rewriting which involves no relational structure at all. While search could and probably should continue using postgres, there's no reason to be involving the db at all to serve the JSON blobs. AC is effectively a document database, not a relational one: just about the only association that's meaningful is packages to authors, and we aren't even doing much to manage authors. Moreover, the documents are static, where any change to the content results in a new ID (in fact, no change often still results in a new id, but that's a different issue). The abstraction we should be targeting is the filesystem, adding DB indexing on top where needed.
I'm not quite as negative on Laravel these days as I have been in the past, mostly due to IDE tooling catching up. I still have a laundry list of complaints with Laravel (including needing that IDE tooling to begin with) but I don't need to rehash them here. The main issue is that Laravel is essentially a monolith, most of which we're not even using, and should we move away from a DB-centric design, Laravel has even less reason to be there. We initially chose Laravel because we had a talent pool with Laravel experience, but now that that's no longer the case, there's no reason to keep it in place, and the existing codebase isn't big enough to call Laravel a sunk cost. Better to rip the band-aid off early.
I'm going to begin some exploratory porting work this week, but I'm inviting the new contributors from TYPO3 to discuss both the design and implementation, so nothing will be finalized until we've gotten input from them.