HawkBitPhp / hawkbit

PSR-7 Micro PHP framework - advanced derivate of Proton by Alex Bilbie
https://github.com/HawkBitPhp/hawkbit
MIT License
65 stars 4 forks source link

The future of hawkbit #33

Open mbunge opened 7 years ago

mbunge commented 7 years ago

Based on Questions by @designcise:

@mbunge Since there isn't a platform where we can discuss this, I'm going to ask this here, I hope you find the time to reply:

So, the Hawkbit framework is very good, but I want to know:

  1. Is the Hawkbit framework being actively developed? Are there any specific future goals, vision, etc. laid out?
  2. What made you develop Hawkbit? Why you felt there was a need for it?
  3. Was Hawkbit intended to compete, innovate, lead, or merely co-exist?
  4. How many developers are working on it? What kind of funding is required and how much time they are able to apply to the project?

Sorry, I'm just asking to assess what the future holds for the framework before implementing it into my projects. I would love to contribute to it in the future, but it's important to know how things are presently.

Thank you for your time! I really appreciate it!

mbunge commented 7 years ago
  1. My vision is to provide a micro framework which is able to handle HTTP and CLI in the same fashion.he developer should be able to reuse it's code, design it's business layer be his needs. Hawkbit should be a supporting tool instead of predefined framework. And yes it is under active development.

  2. I love PSR, phpleague und in minimal set of dependecies and want to create I micro framework which is used the best packages out there bundeld in a nice application layer. I'm also love the style of component-based development.

  3. Hawkbit is built on top phpleague packages and keep PSR in mind. Hawkbit is designed to co-exist whith your code instead of replace code base. Hawkbit does has a small dependency footprint. Last but not least Hawkbit does not force the developer how to design the application bussiness logic, since we prefer to use POPO's for Controllers / Commands (the accessor to bussiness logic).

  4. At the moment I design and develop all Hawkbit packages and manage the whole codebase. I would be appreciate for support or even better contributors!

At the moment I'm in decision making for the future. 3.0 should support PHP 7 only, at it's best. I also need to adjust the command layer, there could bit more flexibility.

BlackScorp commented 7 years ago

Also @designcise i published an article on sitepoint last year https://www.sitepoint.com/clean-code-architecture-and-test-driven-development-in-php/ ignore the TDD Part for a while. If you don't rely on Frameworks, you have less to fear if you want to move further. I put all my logical pieces in "UseCase" classes which has one method "process". Thats it, you can put it in any controller;)

I write whole time a code which is framework agnostic and have in Mind that i might use different library tomorrow.

Don't expect anything and bee free ;)

designcise commented 7 years ago

@mbunge @BlackScorp Thank you for your input.

@mbunge can we have a thread where we can clearly outline the vision, future version goals, deadlines, etc. to streamline development process and monitor progress? And I think the questions you answered, some of that information needs to be in the readme and/or git page so people can make better decisions whether to use the framework or not. For example, after reading your answers, the choice for me has become much simpler to go with Hawkbit over Expressive and Slim (those were the other two I was considering).

Also, I know almost all frameworks rely heavily on URL-rewriting and assume everyone is going to have that enabled by default. But can't we code the framework as such that it would work without URL rewriting as well? For example, ~/website/controller.php?key=value should work just as well as ~/website/controller/value. I think Expressive supports both.

@BlackScorp I personally favor speed, and have always developed custom frameworks for that very reason. Right now, I'm thinking of building all my projects atop microframeworks because they're following a standard (PSR), and it would be easier to switch between frameworks. Do you believe it's better to go a custom route, or use a PSR-based microframework? I would like to hear your thoughts.

BlackScorp commented 7 years ago

@designcise youre working with PHP you can just make your webpage faster with another server and loadbalancer before your webserver, you can scale everything.

if you want to go really fast, take a look at phalcon, which is an extension to PHP written in C++ you will not get faster than that;)

PSR = is a standart and every framework agreed on it. Laravel, Symfony, Zend etc. so PSR you will get everywhere.

Personally i prefer microframeworks because you built less dependencies, a microframework has no much to offer for you. You have just a router, event dispatcher, DI container, rest of the application has to be done by you and you can develop it framework agnostic and switch the framework everytime.

On the other hand. iam already sick of writing the 100th profile page, and picture upload and administrator for the users etc.. for those things a fullstack framework is way better.

So my thoughts, write your code framework agnostic, even in full stack framework. You can beginn with Micro Framework and go to Fullstack if needed. And also dont use ORM. At some point you will split a big application in microservices. You Repositories instead of ORM directly in Controller.

Also i would not care about future goal of the framework etc. iam still using for some Projects the Kohana Framework which is not developed anymore. Also iam using Silex framework, which also has not that many updates lately. If a framework has no updates but you like it, make pull requests. Without PRs a developer loose interests on his "Baby", if the developer dont response to anything, move further. You can nnot make plans to the future right now.

See the framework as a "Date" use it, love it, just don't marry it. Framework is a tool to help you, not THE holy grail of your application.

Hope that helps. Cheers

designcise commented 7 years ago

@BlackScorp Well it's always good to have a vision and goals for a project to determine where it's heading and if it aligns with what you want for your project. Obviously, future has uncertainty, but to know the direction in which something is heading, makes it easier to plan for it.

By speed, it's not only the speed at which a page gets processed, I meant other factors such as the framework being lightweight (free of unnecessary bloat and code), which has always been my goal developing a framework. For that reason, microframeworks have caught my eye, as they tend to be minimal in their approach. Hawkbit, in particular is less intrusive which is why I'm more inclined towards using it.

designcise commented 7 years ago

@mbunge can we setup a hawkbit documentation website maybe? I can help write it. If we have good documentation for hawkbit, more users would likely use it, and it will help grow the community.

mbunge commented 7 years ago

@blackscorp I have to heavily agree to you. A framework (micro / macro) or component need be a tool that fits the job. I wrote an orm, and database layer and now I'm using asynchron microservices with a simple messaging architecture using redis pubsub. So yes stop using orm 😉

@desingcise yes we could do that. I would suggest a repo and setup github pages.

But please keep in mind, I develop hawkbit beside my job and I stopped development on Sundays 😉

mbunge commented 7 years ago

Good news!

I've created a new project for Hawkbit 3.0 (Rough Autumn) -> https://github.com/HawkBitPhp/hawkbit/projects

designcise commented 7 years ago

@mbunge that's great! for version 3, can we also try to add more choices to the container and router maybe? See Zend Expressive's pipeline config file, something similar to that perhaps? Have an interface for container and router perhaps, so we can build adapters for other offerings out there?

mbunge commented 7 years ago

@designcise Could you please declare "more options"? Would you like to be able to add another container or router?

The Pipelne config file is very special. Hawkbit do have PSR-7 ready middleware integration with league route and you could also declar reoute in a separate file. In case of freedom, each user of hawkbit should be free to use awkbit at it's own needs.

We could supply best practice or receipts or something similar to this.