<story><title>Roll Your Own Frameworks</title><url>https://blog.startifact.com/posts/roll-your-own-frameworks/</url></story><parent_chain><item><author>helldritch</author><text>I agree with a lot of what this article says.&lt;p&gt;I&amp;#x27;ve recently started a new application in PHP which has very strict time &amp;#x2F; performance requirements. I could build it in another language, but I&amp;#x27;m most familiar with PHP, the thing would take me 4x as long to build in Rust.&lt;p&gt;The default frameworks (Laravel and Symfony) are very slow out of the box, and doctrine &amp;#x2F; propel are pretty slow as well.&lt;p&gt;I&amp;#x27;ve instead built something entirely brand new using Swoole and an assembled set of very fast and very light Composer packages (namely Fastroute and PHP-DI) and everything else I&amp;#x27;m building myself (compromising on reusability and full-featuredness in return for raw performance).&lt;p&gt;I&amp;#x27;ve split the code in to two: one half is the framework, it&amp;#x27;s concerned with routing, dependency injection, models and hydration, event handling and responses. The other half is focussed on the business concerns: creating users, creating authentication token, performing searches.&lt;p&gt;There were a few challenges: moving from single row, single model queries to hydrating complex joined collections was a major multi-day challenge, but the end result is that when a request has all the data it needs cached, it responds in ~3ms, when it needs something from the database it responds in ~10ms.&lt;p&gt;I was apprehensive when I started, and a half decade ago this codebase would be an unmaintainable mess, but I&amp;#x27;m finding it a joy to work in: there are few layers of abstraction, not a single line of code is wasted, and when something goes wrong there&amp;#x27;s no magic obfuscating the true problem.</text></item></parent_chain><comment><author>kwhat4</author><text>This is one of the primary reasons most people hate PHP.  Let me ask a simple question:  What does the documentation for your homegrown framework look like?  Having worked for several organizations that decided to roll their own framework in PHP, it is an absolute nightmare. No one else knows how it works or how to use it and it usually comes with no documentation. Furthermore, you don&amp;#x27;t get any updates or bug fixes unless you write them, taking time away from working on the project that is being held up by your homegrown solution. There are plenty of fast, low bloat, PHP frameworks to choose from: Phalcon, Slim, Luman and Silex just to name a few.  I guarantee they all have better documentation and support.  If you need some custom functionality, extend one of these existing solutions to suit your needs.  Please, please stop reinventing the wheel for production code.</text></comment>
<story><title>Roll Your Own Frameworks</title><url>https://blog.startifact.com/posts/roll-your-own-frameworks/</url></story><parent_chain><item><author>helldritch</author><text>I agree with a lot of what this article says.&lt;p&gt;I&amp;#x27;ve recently started a new application in PHP which has very strict time &amp;#x2F; performance requirements. I could build it in another language, but I&amp;#x27;m most familiar with PHP, the thing would take me 4x as long to build in Rust.&lt;p&gt;The default frameworks (Laravel and Symfony) are very slow out of the box, and doctrine &amp;#x2F; propel are pretty slow as well.&lt;p&gt;I&amp;#x27;ve instead built something entirely brand new using Swoole and an assembled set of very fast and very light Composer packages (namely Fastroute and PHP-DI) and everything else I&amp;#x27;m building myself (compromising on reusability and full-featuredness in return for raw performance).&lt;p&gt;I&amp;#x27;ve split the code in to two: one half is the framework, it&amp;#x27;s concerned with routing, dependency injection, models and hydration, event handling and responses. The other half is focussed on the business concerns: creating users, creating authentication token, performing searches.&lt;p&gt;There were a few challenges: moving from single row, single model queries to hydrating complex joined collections was a major multi-day challenge, but the end result is that when a request has all the data it needs cached, it responds in ~3ms, when it needs something from the database it responds in ~10ms.&lt;p&gt;I was apprehensive when I started, and a half decade ago this codebase would be an unmaintainable mess, but I&amp;#x27;m finding it a joy to work in: there are few layers of abstraction, not a single line of code is wasted, and when something goes wrong there&amp;#x27;s no magic obfuscating the true problem.</text></item></parent_chain><comment><author>kbenson</author><text>&amp;gt; I was apprehensive when I started, and a half decade ago this codebase would be an unmaintainable mess, but I&amp;#x27;m finding it a joy to work in: there are few layers of abstraction, not a single line of code is wasted, and when something goes wrong there&amp;#x27;s no magic obfuscating the true problem.&lt;p&gt;I&amp;#x27;ve &amp;quot;rolled my own&amp;quot; quite a few times this way, with web frameworks and ORMs&amp;#x2F;query engines, and while I agree it feel that way, I would add the caveat it feels that way &lt;i&gt;at first&lt;/i&gt;.  Eventually, whether that&amp;#x27;s 6 months or 6 years, you end up cursing the framework because either you&amp;#x27;re spending a significant chunk of time implementing features that you didn&amp;#x27;t need but now do, and would have either been included in a framework when you started, or you would have just been able to upgrade your framework to a newer version to get it.&lt;p&gt;Unless the project has a &lt;i&gt;very&lt;/i&gt; tight scope, the eventual drift in needs causes friction when it comes up against the very targeted capabilities of what you designed for yourself because it only implemented what you needed when you wrote it.&lt;p&gt;Writing a web framework is useful and fun, as is writing an ORM.  At least for the first 75% of features.  People should do it, if for no other reason it makes assessing other ones for whether they are suitable for your needs much more easy and accurate as your knowledge increases.  But 5 years from now when you (or whoever inherits it) are realizing there&amp;#x27;s a security issue you need to patch in your home rolled framework, and you aren&amp;#x27;t quite done patching the security or performance problem that was found last week, you might reassess how good of a choice rolling your own was.&lt;p&gt;Symfony and Laraval might be slow, but there&amp;#x27;s a slew of other PHP frameworks to choose from that range from full stack to micro frameworks[1], and those probably deserve a look for anyone in the same position considering the same move.  Maybe rolling your own still comes out looking good, but it&amp;#x27;s not something I think should be attempted in production without quite a bit of consideration as to the eventual implications.&lt;p&gt;1: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.techempower.com&amp;#x2F;benchmarks&amp;#x2F;#section=data-r18&amp;amp;hw=ph&amp;amp;test=fortune&amp;amp;l=zik073-f&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.techempower.com&amp;#x2F;benchmarks&amp;#x2F;#section=data-r18&amp;amp;hw=...&lt;/a&gt;</text></comment>