What is Fat-Free?
What is Laravel?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Fat-Free?
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
This compact framework provided me flexibility. I can implement my own design pattern either MVC or something else. What caught my attention the most was its built-in ORM that can accommodate SQL and NoSql database. That means I can have my MongoSql and SQL queries written by those compatible raw sql statements but still creates ORM models the same way as nosql. Consider for example: $user=new DB\SQL\Mapper($db,'users');// for sql db $user=new DB\Mongo\Mapper($db,'users'); // for mongo db then $user = $user->load('id = 1');
Thanks to its high modularity, I can add more fat to my liking. There's also Cortex ORM f3 extension which handles join tables. Also, handles sessions, routing, and config with ease and let you organize them neatly. That's just a few of the handful features without much weight and with fast performance. One drawback is smaller community, but didn't disappoint me.
I moved from .NET and Rails to Laravel, and since then never thought to go back. I feel Laravel framework has the capability to overcome all modern frameworks.
At Soft Pyramid we are developing rich business applications using Laravel Framework, and never feel any limitation even for complex reporting.We have written REST apis, complex ERP solutions and found awsome in all areas.
I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here: https://email@example.com/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.