What is CakePHP?
What is Django?
Want advice about which of these to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using CakePHP?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The main pro of CakePHP is "bake" functionality and use of conventions, which, if you follow them and buy into them you can really create some complex, large applications quite fast. Faster than any other PHP framework I've ever used, and I've tried all the popular ones.
However, my issues with Cake are as follows:
The ORM is slow. Slower than many of the alternatives. It's queries sometimes do strange things like querying 2 tables separately instead of using a join and I've often faced memory issues stemming from the ORM.
The code conventions, while since 3 they have adopted PSR-2 are still a long way to go to being as compliant with the many PSRs as say, Laravel and Symfony. For example the controllers have an "initialize" method which is doing what you would/should do in __construct. Bugs me.
The template layer needs to be Twig and not the ctp one. This is where the conventions fall apart and I've seen controller code, and tonnes of php logic in views because ctp offers nothing useful, unlike twig or blade templates which are very clean in comparison.
That said I work on a project with hundreds of models and controllers and it holds up really well. I couldn't imagine the same application in Laravel or Symfony. It would be a mess.
CakePhp has is own Comunity and its very coprative they helpd me lot wen i wind no way to resolve a problem then i go for googling and Stack OverFlow but when we could not find any answer then we have to just post and shere issue with CakePhp Community and get answer Shortly
I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here: https://firstname.lastname@example.org/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3
We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:
- Go, the server-side language from Google
We built prototypes in both languages, and decided on NodeJS:
- NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.
- NodeJS acts as an HTTP-based service, so exposing the API was trivial
Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.
The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.
All backend code is done in node.js
We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.
We've written a few internal modules including a very simple api framework.
I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.
Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver. It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs. Also I use nodemon which takes away the effort to restart the server after making changes.
Django takes the hassle out of building an enterprise web application using Python.
- admin app for administration
- ORM for deploying against different database vendors
- social auth package for authentication with enterprise IdP
- guardian package for authorization
Our backend was written in Django. We took advantage of the ready-to-go admin interface as a go-to solution for the client to be able to authorize his users, as well as other functionality, while most of the work was done through the Django Rest Framework.
CakePHP is used because it is a very feature-complete, battle-tested rapid development framework. This saves us months of development time because the API's do most of the work. There is also an extensive plugin and community built around this platform.
Hands down the best Python web framework I've used. Very easy to extend and add apps and go from 0 to full project quickly and painlessly. I built a fully authenticated project with a single endpoint in less than 30 minutes.
CakePHP is one of the most mature and developed PHP Frameworks available, it brings order to Chaos and the core team are a decent bunch of people who really care about the project
정말 편리하고 많은것을 알아서 제공해 주는 프레임워크 이다. 책의 예제만 진행해서 많이 써보지는 못했지만, 쉽게 쉽게 웹을 개발 할 수 있는 점이 매력적 이다. 게다가 orm 이 기본으로 내장 되어 있고 db 도 sqlite 가 기본으로 되어있어. 그냥 django 만 설치하면 바로 웹개발이 가능하다.
django는 저의 무기입니다.
django 이외에 flask로 간단한 restful api를 만들면서 느낀점은 framework 보다 언어가 중요하다는것을 알았고 django가 얼마나 큰 framework인지 알게되었습니다.
저는 signal 사용을 좋아합니다.