Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have to create a REST API for a mobile application and I don't really know how to begin it.
I read some articles and tutorial about REST in general, but I didn't find a complexe API example written in PHP.
So after more researches I choose to use a micro-framework (rather than start from scratch). A full framework like Symfony2 or Zend provide some methods that I will not need, and I think they are too big for.
Because I already worked with Silex PHP, I choose it.
But one question stay in my mind : is Silex a good choice to create a (future) big API ?
The API will evolve and could be more and more complexe (understand more URI will be avalaible in future, because we have goal to migrate from SOAP to REST).
Since Silex PHP uses a single file convention, I'm a little scared to use it (because file will be more and more larger, and I supposed with performances falling).
Also I would like to cache on server results (additionally with HTTP caching) when necessary, to reduce queries to database (MySQL).
What do you think and what do you advise ? :)
Silex is not a bad choice for building out an api service. I would recommend maybe starting with Silex Kitchen Edition for some decent organization and other useful configs and strip out what you don't need. Also, I would look for existing restful projects written in silex/symfony. As far as scalability you should read this post from Igor Wiedler one of the creators of silex.
Silex is a microframework meant to be used in small projects. It's suitable for small websites with low traffic. It is also a good way to introduce yourself into some concepts like dependency injection, without introducing too many abstraction layers.
They've recently introduced the target in their website as "single-file apps", giving you a bit of the target scope for the framework.
I think it should be fairly accepted fact that Silex is not suitable for anything big.
Silex will not perform badly if your project works, but it will not be the nicest to work with once you start growing, as it will not help you too much. Symfony uses concepts you'll see in Silex and is a full stack framework you can use for bigger applications with lots of bundles, plugins and a big community there to help you.
Edit:
Note I cannot delete the answer as it has been accepted. I haven't used PHP in years now, since then, Silex has changed their approach from "microframework" to being just a library it seems. Whatever the case, the down-voting I believe must come from people involved with the project, probably upset of having created something which didn't take off as they may have hoped.
Just read the product docs, this was a request for an opinion which was given and accepted. I don't think this question belongs to stackoverflow anyway.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I come from a Codeigniter background. I've used it for three years and really like it. It's simplicity is great.
I've built massive sites with Codeigniter, but I'm looking for a new PHP framework to learn.
The main reason for this change is a potentially big project on the horizon. It will not have many users (perhaps 100 at most), but the outbound traffic produced by the server will be huge. The project will transmit thousands of files (ranging in size from 1mb to several hundred mb) via FTP, one after the other. It also deals with users uploading hundreds of files.
The key for this project is speed. The system needs to fly through the running of the scripts (it runs a long script every time a file is sent via FTP to gather the file, it's type and it's destination) as quickly as possible to minimize performance issues. I'm aware that the transmitting of the files will only be as quick as the server can do it, and really as quick as the slowest bottleneck, but here I'm trying to minimize the bottleneck in the code as much as possible.
After a bit of research, I like the look of Laravel and have installed it to get to grips with it. But it's could its speed be an issue as its been tested to be slower than Codeigniter? Will heavy traffic and a lot of PHP parsing slow down the I know that Phalcon is based on C thus making it the fastest framework, would Phalcon be the better choice?
Any thoughts are much appreciated :)
I am unsure if your question will be taken down as it being an opinion (you know according to guidelines and all)
but IMO - despite Phalcon being fast for its C build, I find (being Laravel 3 user transitioning from Codeigniter before it retired) with Laravel 4 now - it has a lot of integration with known networks and architectures.
Not to bash Phalcon as I have very minimal usage of it but here are some bullets for Laravel:
Easily modular with composer: all packages can be imported in with the current PSR standards from composer for rapid deployment of dependencies which Codeigniter was lacking.
It can follow any style you want it to be: PSR-0 and PSR-4. It's a natural MVC but you can easily go with TDD(or BDD), and other format. Though this is a poor bullet to some but it offers a lot of flexibility on adapting to various works.
IoC is built into the APP. Its very comprehensible and extensives in order to utlize IoC
Taylor Otwell is very active in adjusting and fine tuning the framework. Its a very active thriving community (Laracon NYC just passed, next up Laracon Amsterdam), so you will not be shorted with support.
A lot of know application out there are pre-integrated with the framework from Queues (beanstalk, IronMQ) to mailers (swiftmailer), and even Cache systems (Redis or others). The interface is straight forward in terms of functions - worse case? just extend and you are ready to roll out.
Readability: a lot of the structure and how the ORM (if you choose with the native ORM of Laravel which is called Eloquent) is all about readability of your code despite the underbelly being complex. So it will scaled right (a lot of people who switched over states the same).
Some further readings from those who switched over and wondered like you:
http://www.web-and-development.com/laravel-vs-codeigniter/
and
http://mulzer.tumblr.com/post/24141993116/12-reasons-you-should-switch-from-codeigniter-to
Now a bullets for Phalcon vs Laravel in speed:
With Laravel + APC + a few other tweaks you can achieve something close to it while giving you all the flexibility that you gain from Laravel.
Finally if you need a side by side comparison:
http://vschart.com/compare/phalconphp/vs/laravel
If it's just about speed take a look at this benchmark:
http://systemsarchitect.net/performance-benchmark-of-popular-php-frameworks/
I would def go with phalcon since it's created on c level basically the same as if it is php itself.
EDIT:
As of the writing of this edit, the site mentioned above is non-functional. Below is a snapshot from archive.org:
https://web.archive.org/web/20160329072449/http://systemsarchitect.net:80/2013/04/23/performance-benchmark-of-popular-php-frameworks/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We are planing to make a new system to replace our 10 year old system, in doing so we are considering to make the new system in Laravel. Now I have concerns I will have to hack the whole thing and make it a mess to make it work as we wish. So I am asking if someone knows a better solution for it, or can tell that it is already made in it.
we need:
ftp, sftp, which are cron triggered.
mail daemon which is cron triggered.
easy way to implement multiple factories and easily to encapsulate them (i am thinking to use the model part for it)
easy possibility to switch the global database connection
inter server connectivity
caching functionality like memcache built into the database layer and object layer
possibility to tell the framework which pulls get stored in cache
an easy Templating system, ye i know i can make one easy, but some which is already done in Laravel would help :)
we have our own servers so module installations are not a problem.
Unit test implementations on factory based systems.
All suggestions are welcome, if i am by any chance in the wrong stack overflow part please just say in which section i should move it. Thank you in advance for all feedback :)
UPDATE->
The requierements above are minimum requirements for us/me to consider the framework good enough. If somone is able to point to tutorials how to do the stuff with laravel. Please provide links. In special Unit testing Laravel controllers, cron setup from Laravel... and so on..
This is truly a question only to be answered by you and your team (in terms of effectiveness, language understanding and framework pattern knowledge).
Laravel can surely withstand such projects and migrations but most of the frameworks out there can do, personally I've been using Laravel and Cakephp in terms of PHP frameworks and find both of them quick, efficient and easy to use (with Laravel code a bit more easily to read through large projects).
On the other hand there are frameworks out there which efficiently do what you need quicker and easier than most php frameworks, django (python) is one example, stable, lightning fast development (if you are already familiar with python concepts) and proven (instagram, disqus etc).
Nearly all frameworks have known RDBMS support, but are a bit back in terms of NoSQL support (yet you can find plenty of projects that provide support for NoSQL), Laravel can easily switch DB's but compared to the "DB router" feature of Django I believe it feels a bit behind on how much detail has been put to it.
Laravel is a beautiful framework, but this isn't a stackoverflow type question. None of us will be able to really give good advice, other than say Laravel is good.
Let me refine the question. I am not asking for opinion if i am using the right framework, i need some hard data.
I already know Zend 2 (working with it 1.5 years) and it is to bulky and to developer footprint heavy for our project(our logic would have to be developed into the damn thing... just not practical).
I already work with Cake, and it is to simple for us,
Symphony i know to, but it has BIG problems with our structures.
Code igniter is.... to simple... and so on and on...
I am currently reading trough Code Bright Book for introduction of the possibility's from Laravel. And i am half trough. But i have not found anything that tells me it can help my project with the points which are pointed out.
So i am asking again, i need examples of the points implementations in its simplest way for comparison. except in Zend, Code Igniter and Symphony.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've done some development in RoR and I'm now trying to make something in PHP.
I think the MVC architecture is an ideal frame for my current project (users, application data, purchases, etc.)
Is there implementation of MVC on the web that is recommended or does PHP just not work in the same way as Rails and every MVC in PHP must be hand made?
My google fu is weak and I couldn't really find anything conclusive.
These four are MVC frameworks:
CakePHP
Symfony
CodeIgniter
Kohana
I prefer CodeIgniter and Kohana, because they're pretty focused and not bloated at all, and because they both, besides being MVC, are also big on the convention over configuration principle, meaning you don't have to go around maintaining XML/YAML/etc config files of your classes, URL routes, etc.
In particular I like Kohana because it has this nifty file system-based configuration hierarchy (they call it "Cascading Filesystem") which basically means you have even less configuration nonsense to maintain, because based on where you put your app's files (classes, config files, etc), the framework will know which parts of the system will be overridden. So I'd recommend you give Kohana a test run. Beware though, it's relatively new and the documentation is kind of weak, so if your google fu is indeed weak as you say, then you might be better off going straight for CodeIgniter, which has been around for longer and thus has more docs. But I'd still keep an eye on the Kohana project.
Symfony is... too bloated for my taste (i.e. having to run scripts in order to "generate views" and whatnot), but I've seen some large successful projects running on it.
Rails is an MVC framework, for PHP you could use CodeIgniter or CakePHP both of those use the MVC design pattern. CodeIgniter is the bomb.
You can find more discussion about PHP frameworks here: http://www.quora.com/Whats-the-best-MVC-framework-for-PHP
I haven't looked into other frameworks, I have found Codeigniter to satisfy most of my requirements from an MVC framework.
Sure, Theres Codeignitor and Frostbite Framework.. Both are good, and easy to find via google. Here is a whole list of php frameworks: http://matrix.include-once.org/framework/simple
Everyone else pretty much nailed it. The only reason I'm adding on to this question is because you use Ruby on Rails, and as such, CakePHP is going to be the most similar framework for you.
I use CodeIgniter because it's very well-documented and lightweight (with very little magic), but that's just my personal preference. Cake will be most like what you're used to.
I think laravel is best for you. Remember, frameworks are for SSBs Small scale businesses. For large scale businesses you write your own framework with all planning, execution phases etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Facing a need for a single CMS we can use for rapid deployment of customized CMS solutions, I am wondering if anyone can share any constructive feedback, experiences, pros and cons of this, seemingly powerful, piece of software.
The whole story/marketing pitch sounds solid, and from a quick glance at the CMS itself things seem to be put together in a coherent and pretty flexible way. I am however looking for first hand experiences as they usually reflect the real situation way better than anything else.
If you have used (or are still using) ezPublish for something, I would love to hear about it.
Thanks!
Having in mind all good points of eZ Publish you should be aware of bad ones. From programmer point of view: Most of the system was written in php4, and was rewritten in a hurry, to make it works with php5. Lack of design patterns and object oriented approach in kernel, makes system hard to develope with, and to read its code. To add some heavier functionality not supplied by CMS, you can use extension system. Problem is programming extensions is slow and painful (documentation only in code). There is quite good technical documentation on www.ez.no but most of it is for webdesigners.
I'v used ezPublish for quite a while and I can say its very flexible and allows a range of different solutions to quickly be developed with it. The ability to add content types is what makes it awesome.
It can be a little bit slow at times, but with proper caching set up it can also be really fast.
The biggest downside: The learning curve is very steep and long, and there aren't enough knowledgeable eZ Publish developers available in North America.
However, from the beginning I've been fond of its overall architecture, which seems to be elegant, flexible and generally well thought-out. Over time, some things have been bolted on in ways that don't necessarily fit perfectly. But it's pretty amazing what you can accomplish with the core functionality, and overriding and extending the core is clean and maintains good separation.
I would say that if you are in it for the long haul and can afford to train your developers (really, you can't afford not to) then eZ Publish is a reasonably good choice. Once you figure out the platform and develop your own kit of tools, it should be fairly quick to deploy custom solutions.
I will also concur with an earlier answer, that the class system really shines. Caching is always an issue, so don't forget to learn the caching system. Your site can fly on eZ Publish, but you must understand caching to make it do so!
I have Used eZ Publish for some years now.
It was quite difficult to learn it at first and understanding the structure, but when you are on the way then everything would be simple and fast, especially with their new kernel on Symfony2.
I would recommend using eZPublish 5, as I suppose you no longer talk about the older versions, only if you have at least some basic knowledge of eZ version4. That is because the admin is still using the legacy and all the settings are done using .ini files which you really have to know. Nothing hard, but learning curve is definitely steep.
Also using eZFlow will require working with both .ini and .yml configuration files, so you need to understand both config structures.
Further on, as I have been at a presentation for the new admin, which unfortunately will be using YUI as JS framework, and having seen the release plan for this year, I can say you will have to keep the legacy admin if you want to benefit of all the functionalities as there is an enormous amount of work to be done to have everything migrated on Symfony 2.
Even with the announcement of eZPlatform(eZ 6), I am not that confident we will have a really STABLE version anywhere this year.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My team at work is considering to use a framework for developing web sites and applications. Some of the seniors are convinced we should use the Zend Framework because it is easier to pick-and-choose the features so the framework we will be light-weight.
I'm afraid however that they are only looking at the technical advantages that a lightweight framework will have. In my opinion it is better to have a full-stack framework (and I am a proponent of Symfony) because
It will also provide us with a standard way of working without writing new documentation.
If we would like to use new features we would only have to read the documentation to see how it can be used instead of having to build it into our setup of Zend first.
I don't expect all my questions to be answered by everybody but this is what I am looking for in the answer:
Do I have a point here?
Have you been in a similar situation and how did you handle that?
Do you have more arguments that I could use OR could make me reconsider my own opinion?
The context:
I work at a small shop with about 10 programmers. We mostly program PHP. We use a really simple inhouse developed framework and ORM library that are practically undocumented and lack anything but the most basic features (no validators, no transactions, no caching, no authentication)
And why not both? I have been using symfony since 2006, have been a real Doctrine fan for one year, and for a few months, we've reach many steps on the productivity ladder by integrating Zend components directly onto our symfony applications.
The real strength of symfony lies on the decoupling of everything, and the easy extensibility of the framework. You can replace almost every layer of the whole thing. Just copy/paste the Zend directory in /lib/, and add this singleton in /config/ProjectConfiguration.class.php:
static public function registerZend()
{
if (self::$zendLoaded)
{
return;
}
sfToolkit::addIncludePath(sfConfig::get('sf_lib_dir') . '/vendor', 'back');
require_once(sfConfig::get('sf_lib_dir') . '/vendor/Zend/Loader.php');
Zend_Loader::registerAutoload();
self::$zendLoaded = true;
}
And use freely any Zend component you might like.
You might be interested in the new Jobeet tutorial, and especially at the Search part, which uses Zend_Lucene_Search.
Symfony is really easy to use and can get a fully functional site with sessions, caching, unit and functional testing, automated deployment and more up and running in a very short amount of time. You only really need to worry about code to access and display your data. Whist it may not be as lightweight as a roll-your-own implementation, the amount of code you have to maintain will be less.
The Propel/Creole ORM works well, has built in validators etc and is set up to be extensible out of the box.
When transitioning an in-house framework over to Symfony I was able to re-use lots of library code simply by putting it in one of the lib directories that Symfony scans at startup.
Although I've not used it, there is a Zend bridge built into Symfony that allows you to use Zend modules if needed.
Hope that helps.
I think the ZF documentation and community involvement is better. I also like the naming scheme, coding standard and extensibility of it. ZF also seem to get a lot of new features and improvement to existing classes like an open source project, from many different people working on their own pet projects.
I don't really see how Symfony is an advantage for a group of 10 programmers. Clearly you should be able to relatively fast set up a default configuration for new projects, and have lots of extensibility built on top of and in addition to ZF.
How is ZF not "full stack"? It seems to contain every element Symfony does, and then some. Moreover ZF has a "pick your poison" approach, allowing you to use different pieces in different methods. (As an example, we use Zend_Config in lots of different places, just so everyone can expect a reasonably uniform configuration system, even on tiny pieces of code).
I'm afraid however that they are only looking at the technical advantages that a lightweight framework will have. In my opinion it is better to have a full-stack framework (and I am a proponent of Symfony) because ...
It depends a lot on the type of application(s) you're building. If you're building a lot of low-complexity, mostly content-driven applications, then Symfony will shine. On the other hand, if your application doesn't fit into the naked-object paradigm of Symfony (For example, if it's complex and not entirely focused on content management), you may find it more of a hurdle, than a help.
I have limited experience with either, but a good starting point for setting "standards" for Zend is to follow their tutorials for using the different modules - many of them give sane defaults that work for 99% of the projects out there.
I would say it comes down to what you need it for - Zend for flexibility, Symfony for a quicker start and pre-developed standards if your project has no extraordinary needs.