Future of the Flight Micro Framework

[n0nag0n]

Hey everyone,

I've reached out to mikecao via twitter and email to help maintain this repo but haven't received a response from him, so I'm going to assume he won't maintain this repo going forward. He's done a great job so far with creating and maintaining this fabulous and simple framework. This is not an issue to rip on him or anything, cause I totally understand not wanting to maintain something you don't spend your time and talents in. I wish him the best of success on Umami!

Going forward, I will try to help maintain this framework in a fork attached to my github account.

For any future development, bugfixes, and maintenance going forward, please visit https://github.com/flightphp/core (unless Mike chimes in and things change).

Also available on packagist to install via composer with https://packagist.org/packages/flightphp/core

You can install with composer require flightphp/core or update the composer.json file in your project to point to flightphp/core instead of mikecao/flight if you'd like the updated changes.

Thanks again everyone!

[n0nag0n]

Well.......scratch that idea. @mikecao is truly a gentlemen when he has transferred ownership of this repo over to a new organization called https://github.com/flightphp. So with that, we can merge in the work that's been done on the "temporary" flightphp/core repository. For starters, we're increasing unit testing coverage to 100% immediately. When we started, we were at 54% coverage.

Now we are sitting just above 90%. (I like seeing more green :D )

We've already found a couple issues related to Windows users based on feedback from @fadrian06 from his windows environment.

Short term goals are 100% unit test coverage to at least start covering the bases. Dream pipe is 100% branch coverage We'll eventually move this to be called "core". The reason for that is so additional plugins/extensions/features can be created outside of core, but the core module should do 90% of what you would expect it to do. Along with that, the other goal is that we'll have some kind of database package to help getting data from a database (cause most APIs hit a database and return the data).

Things I'm personally bearing in mind with helping maintain this project is that there should be a focus on simplicity and a flavor of "locality of behavior". As I've coded for nearly 15 years, making something complex has been easy, making something simple, that's easy to understand, where others can "come up to speed" very quickly is very very hard, but very very rewarding. You should be able to hop in a code base and get your bearings quickly instead of wallowing in the mire for hours trying to figure out which class your something just bounced in an out of and not scrolling up and down and up and down to try and figure out what's going on.

Anywho, long winded, but there ya go :) Thanks again @mikecao

[krmu]

Thank you for taking over this!

[paxperscientiam]

Cheers @n0nag0n

Thanks @mikecao for all your work

[n0nag0n]

Hopefully we can poor some happy gas on this project and light it up again :D

[cdsaenz]

It's a fabulous idea, flightPHP. I could put it to action immediately, no curve as others. I've always used Codeigniter but wanted a lighter option for many simple static sites that require a "pizzazz" of dynamism. A nice, flexible router, mostly. A way to render a view with ease. Rest is classes/namespaces, and more functions? it's all there via the composer gold and the powerful modern PHP itself. Not using it these days but plan to return. Thanks a lot for the dedication guys, appreciated :)

[n0nag0n]

It's a fabulous idea, flightPHP. I could put it to action immediately, no curve as others. I've always used Codeigniter but wanted a lighter option for many simple static sites that require a "pizzazz" of dynamism. A nice, flexible router, mostly. A way to render a view with ease. Rest is classes/namespaces, and more functions? it's all there via the composer gold and the powerful modern PHP itself. Not using it these days but plan to return. Thanks a lot for the dedication guys, appreciated :)

Yes I agree. Nice and simple! Easy to get something up off the ground that has some flexibility. This definitely wouldn't run Facebook, but it could handle a lot of small to mid size projects if it's structured properly.

[kuopassa]

Please try to retain the original vision:

An extensible micro-framework for PHP

[n0nag0n]

Please try to retain the original vision:

An extensible micro-framework for PHP

I'm planning on keep existing functionality because introducing technical debt with major version upgrades is an awful way to shoot yourself in the foot (looking at you Laravel)

[starfishpatkhoo]

Thank you @mikecao for creating FlightPHP. I've just looked at my old files, and I see that I first tested and compared FlightPHP with Slim way back in 2015. I chose Flight because it was simpler, easily customisable, and yet still very powerful. I have been using Flight on so many different projects since then. For any new projects coming up this year, you can be sure Flight will be my first choice.

Thank you @n0nag0n for taking over and keeping the flag flying high. I appreciate it. I do hope you will keep Flight simple, highly extensible and easy to use. One good simple measurement is by looking at its documentation. FlightPHP's documentation is one (long) HTML page. Slim is more complex. Laravel is .. While this is not a full picture of a system's capability/ease of use, it is a quick and dirty evaluation factor for similar projects that aim to solve the same problem. So I hope you will keep FlightPHP to be micro and extensible and (for me) easy/joyful to use ..

I think at its core, I'd like to see FlightPHP keep to its core principles, keep updated, bug fixed, secure, and add convenience hooks/features for developers to add different things in the future.

• Adding caching (eg. redis, ...)
• Adding a data modelling layer (eg. PHP Active Record, ...)
• Adding authentication and authorisation layers before routes (noted your works on route grouping and filters - good idea, looking forward to hearing more!)
• Provide data and APIs easily (eg. GraphQL, ...)
• Consume other services/APIs (eg. Google, Telegram, Xero, HootSuite, ...)
• Implement authenrtication and authorisation schemes (eg. Passkey, captcha, OAuth, ...)

I feel none of thse should be baked into FlightPHP (micro), but it should be easy to add them in (extensible)... Sort of like how there is a common/structured/suggested easy way/example to add and use different renderers - Twig, Smarty, etc.

Perhaps what's needed also is more examples of structured ways of how Flight can be extended and used - I use Flight with Twig and PHP Active Record (I call it FTAR, awesome combi).. I'd be happy to help write up some examples somewhere of how to add them.. Maybe we need a different repo that just has documents and examples of how these things can be added to Flight, and best practices etc..

[n0nag0n]

Yes I'd like to keep Flight simple at it's core with some extra extensions that could be different packages within the flightphp organization. It does feel like flight needs a few more things for it to be more feature complete with what I'm hoping for.

[n0nag0n]

An article that resonates with how I think. The older I get, the simpler I want stuff. https://ahastack.dev/concepts/simplicity/

[starfishpatkhoo]

An article that resonates with how I think. The older I get, the simpler I want stuff. https://ahastack.dev/concepts/simplicity/

Me too! :) That's why we're all here at Flight and not Laravel.. 🤣

[cdsaenz]

An article that resonates with how I think. The older I get, the simpler I want stuff. https://ahastack.dev/concepts/simplicity/

Same here at 55! :) I think I spend a lot of time trying things that I quit because they're too complex. Like React: VueJS was better but still too much, now I use AlpineJS, as FlightPHP it comes with minimal docs, you soon fly away.

Me too! :) That's why we're all here at Flight and not Laravel.. 🤣

Relatable. As the (nice!) article says "they're interesting challenges" and I support them but... Laravel is a zillion packages and a myriad (helpful of course) classes ecosystem that update from day to day. I used it in version 7 and now I need to start from scratch :D There's a place for it! It's beautiful! But head-scratching, too much for me. Then in the middle I have my eternal Codeigniter now in version 4, sort of a Laravel light now: You're free to code a lot. With Flight I can cover the rest, an API layer, an Endpoint/Form processor, or simply a views manager to avoid repeating header/footers in static HTML! :D @starfishpatkhoo thanks for the PHP Active Record tip. I was looking for something like that to cover what CI does in Flight!

Conclusion is: modern PHP and composer packages do a LOT today. You don't need the framework getting in the way of the basics :)

[n0nag0n]

Conclusion is: modern PHP and composer packages do a LOT today. You don't need the framework getting in the way of the basics :)

I've messed with Laravel a little bit, but in my role at the company I work for, I need to ensure that developers can get up to speed as fast as possible. Learning Laravel is like learning a new language. It has a tool for just about everything, but learning that tool takes a lot of time. And just the basic docs (while very detailed) can be overwhelming for a new dev to learn. At my work, we created our own internal framework that was robust, but very simple to understand. Devs that use it love it and appreciate the simplicity, but it can still do really robust things in a 600k line codebase.

This is why I really like Flight (and Fat-Free for those that have used it). Understanding the basics and being effective with it in a short amount of time is very important to me. And the code should "document" itself. There are some things with flight I'd like to change so that existing functionality is working, but that maybe what the method or function does is better conveyed through the variable or method name.

[cceconi]

Hi, I've also messed with FlightPHP 8-9 years ago, but switch after to SlimPHP. If you don't know this one, I encourage you to try it as it already has some of the features you want in FlightPHP.

[cdsaenz]

I've messed with Laravel a little bit, but in my role at the company I work for, I need to ensure that developers can get up to speed as fast as possible. Learning Laravel is like learning a new language. It has a tool for just about everything, but learning that tool takes a lot of time. And just the basic docs (while very detailed) can be overwhelming for a new dev to learn. At my work, we created our own internal framework that was robust, but very simple to understand. Devs that use it love it and appreciate the simplicity, but it can still do really robust things in a 600k line codebase.

This is why I really like Flight (and Fat-Free for those that have used it). Understanding the basics and being effective with it in a short amount of time is very important to me. And the code should "document" itself. There are some things with flight I'd like to change so that existing functionality is working, but that maybe what the method or function does is better conveyed through the variable or method name.

I briefly tried Fat Free, Slim and some others. All have something nice to say. But I found Flight clearer (in the end it's what you click with!); and while I work alone, I jump from WordPress to Codeigniter to eventually Flight, and I need to be able to go into it without re reading the docs or re learning everything. It should document itself, exactly.

What you mention as the internal framework, or my custom library as I'd call my own is of high interest to me. I cannot emphasize enough how important is that we don't lose the focus of what PHP can do by itself (and its powerful packages). That means to me that I could potentially reuse code from Flight in WordPress, Codeigniter, or whatever comes tomorrow.

[n0nag0n]

Hi, I've also messed with FlightPHP 8-9 years ago, but switch after to SlimPHP. If you don't know this one, I encourage you to try it as it already has some of the features you want in FlightPHP.

So I actually got really angry with SlimPHP and vowed to never try it again. I was on version 3, and we implemented some smaller projects in slim and shortly version 4 came out and I wanted to start punching walls. Slim became anything to everyone who could use anything and whatever they wanted. I felt in their quest to be inclusive of whatever container, and whatever request, and whatever class x you wanted in the framework, you could choose and implement it that way. In doing so, Slim lost it's simplicity along the way and a simple skeleton project had a bunch of dependencies and "flavors" of how to do it. It just felt so convoluted, it made me sad and that's when I moved to Fat-Free. I never realized just how important it was to NEVER introduce technical debt through upgrades of the framework. It might mean you have to get a little creative from time to time, but something I coded 5 years ago, should still work and be secure after 5 years if I just run composer update. Those slim projects, we never were able to allocate the time to refactor them into something else, and eventually those projects just died and we scrapped them.

[n0nag0n]

If you're interested, some of my opinion on maintaining the same codebase moving forward actually comes from a unique PHP framework you've probably never heard of called Trongate. https://trongate.io/about. They are pretty performant, have a desktop app (wha????), have framework wars with other PHP frameworks, and have a policy of long term API stability. They are pretty cool guys too.

[n0nag0n]

Also...