im trying to create a Single Page Website with DurandalJS in the frontend and Laravel as the Backend. Do you think this is a good Idea?
If yes how would I do the following:
What would your recommendation for the basic interaction between both frameworks be?
Would you rather have all the computation done in JS instead of Laravel sending calculated and styled returns?
How Do I setup Laravels controller in order to only get dynamic Data for, say a Div, instead of a whole page?
How can I adjust the browser URLs?
I hope I was specific enough, thank You in advance.
Laravel does not actually care about what framework you use to build the Frontend. Laravel is just a framework that helps you build your application with. It gives you great advantage with respect to the time spent and effort.
You can use any frontend framework that you want to build your app with. I have actually not used Durandal, but from the first look of it here is my opinion.
Durandal is built on top of jQuery, knockoutJS and requireJS. It also has a MV* architecture in place with support for eventing as well. So you could basically define routes on Laravel and initiate the communication between both the frameworks through events and ajax. Again this completely depends on the functionality that you are building.
In the overall flow of your app, consider Laravel as a Model that just gives data from a source to your app and Durandal as your views and controllers. This way, it will keep your data flow cleaner and easier to build. Computation of your functionality depends on how important and secretive the app is. If there are functionalities/implementations that you need to be secretive about, you can keep it on Laravel and just send computed data to Durandal. If its a web app that you are building, then keeping all implementation on the JS is just a right click away from knowing what and how you have built it. One can just see how the implementation is done just looking at the Javascript source of the web app. If you are building Mobile Device App, then the case is different.
Take a look at Restful Controllers. Will give you an idea on how to setup controllers to return only data. But if you need to return the div itself, then you can make use of the Basic Controllers of Laravel to perform them.
You can setup cleaner routes for the browser URL's. Take a look at Laravel Routing
Related
I've run into a problem that I'm sure many new/junior web developers are facing. Before I state the problem, it's best if I first list the events that drove me to the "issue".
Step 1 - The Front-End:
I followed tutorials which allowed me to create a Vue project using the vue-cli - I now have a nice front-end ready to go, albeit it is in a way "standalone". It sits in its own directory.
Step 2 - The Back-End:
I move on, I start to look at the back-end. Laravel plays well with Vue so I go with it. Once again I follow tutorials, I create a database and an API. Fantastic.
I now have the barebones core elements for a CRUD application. However, the way the back and front end are connected seems to be convoluted (although this may be due to my inexperience and improper understanding).
Solution 1:
Some tutorials insist that the Vue project is "re-created" within the Laravel directories so Laravel is in charge of rendering the views.
Solution 2:
Others, from what I can tell keep them physically separate and have the front-end interact with Laravels API only.
What are the best practices when it comes to stack architecture? Should we aim to bundle the stack together as proposed in solution 1? Is solution 2 even possible or is that due to my misunderstanding? If it is, how is deployment handled?
From my point of experience, both are correct and the answer depends on what you want to build 😀
First, if you have a simple website and you want to make the front-end of it in vue and it is only this one website, you can put it all together and make the frontend in Vue, which is handled by laravel in the backend and you are done.
Second, the step further, is for this case, that you can have several frontends for your project. Example: You have a website and several (native or universal) apps to display your data. In this case, you can build an API, that handles all the logic, all the business secrets, and this stuff, that no one should know in detail. After that, you are free to build any frontend (Vue, native, plain-HTML), whatever) you like, that's the only purpose is to display the data the API gives back (with some little logic in it, of the cause, but the secret business logic is hidden in the API). You can even outsource the generation of an app, so you build the website frontend in Vue and another one can build an ios-app with swift or an android app with kotlin.
Hope, you get the point, the answer is, as often: it depends 😉
I'm starting a new large-scale application and after hearing a lot about VueJS + Laravel combination i thought of using it. I followed Laracasts' Learn Vue 2: Step By Step series and some tutorials to understand how it works.
But have few questions in mind:
Why do we even need to use Vue with Laravel. I understand that we can create component like <user-profile></user-profile> in Vue, and then use it in Laravel Blade. But it looks like over-complication things? Firstly we pass data from controller to blade, and then further pass it to vue. Why do we need to do that?
Laravel and Vue both have their own routing system. Which one to use?
How to structure an app using Laravel + Vue
PS. I'm making an application that will mostly be used on mobile devices.
moved from comment
Why do we even need to use Vue with Laravel.
Although you probably already knew, Vue is just one of many javascript frontend frameworks (libs?) You can consume the data send from the server any way you want. Vue is just the sister-framework of Laravel. The only thing you can probably say as to why they are mentioned together is that you can "talk" (interface) easily between them using json objects. Javascript is meant to make your page interactive, have behaviour. Use it when you need this.
Laravel and Vue both have their own routing system. Which one to use?
Whatever you want, do you want a "single page" (blade) that is rendered in 3 different pages by Vue, say like some kind of Wizard form. It really depends on where you want to put the load. I think you can think of use-cases where client side page rendering would be better, but most of the time server sided will be a great choice.
Single page applications are more snappy (faster) after initial load, but server side rendered applications are better for SEO in general. There are also ways to let a SPA render on the server to improve SEO however. And this we we can keep the discussion going for some while.
How to structure an app using Laravel + Vue
Laravel has already an example vue file under resources/assets/js/app.js. So it is safe to assume you can put everything there.
React's website states:
Lots of people use React as the V in MVC.
From this, I am inferring that React does not play the "M" and the "C" roles in MVC.
If this is correct, it means one cannot build an entire web application solely with React JS.
Then, how?
Does React require a complete MVC framework for the backend, such as Rails or Laravel?
Can React simply pull data from a backend where a framework, such as Rails or Laravel, would be setup as a web API?
Does React not need any of this and works in a totally different way (in other words: am I completely missing the point)?
MVC is just a term for structuring data flow in an application.
You do not need MVC to build an application, even if it might help.
What React does is that it specializes in building isolated components - where the data flows in a single direction(the von neumann model of computing).
This is very nice because you can build an application with the premise that everything is always rerendered when data is changed, thus avoiding hard to read "two way bindings".
The thing is that it's very inefficient to rerender every view when some minor data is altered, but Reacts "Shadow DOM" optimizes this process, and makes efficient rerenders.
But React does not care where it gets data from. You could build a backend with nodejs/php/ruby or whatever you want. How you communicate and send data between the frontend and the backend is also left up to you. You could use jquery/socketio/superagent or whatever you want.
You can also combine React with any other framework, or just skip frameworks all together and fetch the data directly from a react component.
Facebook, the creators of React, have their way or organising projects called flux, which plays well with react(even if it is not needed).
https://github.com/facebook/flux
i have to start a new project, a webapp with lots of forms and screens and i really don't know which technology fit best. The application is an ERP like app, with very few animations and lot of forms. The goal is to reduce at minimum reloads and waiting time, it has to be as close as possible to a normal desktop app (a lot of work to look like a marvelous VB6 app :-)
On the one hand we have client side MVC (backbone). It's cool to have all the code running on client but in my mind this implies repetition of lot of code (for example all models definitions) from server (PHP + Fuel). Sure once loaded all the informations task like paginations or grid work without any delay but it also present some problems of synchronization (other users can change data and i have to manually invalidate data on client).
On the other hand we have pjax. The idea is to make all the templating and so on on server, just implement a logic to return the page without the frame for pjax request or full page on new requests. No code duplication, very simple client side.
I've read the the story from basecamp and from twitter and both the point make sense to me. You can't relay on visitor computer (features, performance ...)
The more i think about it the mode i like pjax over MVC, but maybe i'm missing something. Which are the MVC advantages over pjax or pjax disadvantages over Client side MVC ?
Thanks a lot
Backbone.js is good for heavy, single page web apps that never truly post back, but have lots of ajaxian things going on, interdependent cascading dropdowns, etc. It has a very good API for events and collections. If you have plentiful client side javascript, it can be a helpful way to organize it. It is opinionated in the sense that it expects your server-side architecture to be RESTful by default, and you have to make some effort to use it for non RESTful APIs.
The project I'm working on is an ERP web app as well, with asp.net MVC on the server-side. I've learned that Backbone (with handlebars as the templating system), and .net mvc really don't play together that well. If you go Backbone, you really have to go full-hog (controller methods serve up json, that's it). On pages in this app that are more or less 'normal' web pages with some forms, Backbone is the wrong choice.
I just googled pjax for the first time, so I've basically just read the short description at the top of the page, but I suspect that might be the way to go for your scenario, in keeping with Keep It Simple Silly principles.
Doing anything in the terminal, git, etc multiplies my learning curve in attempting to quickly develop an app using CodeIgniter. I realize the need for a Javascript framework and would like to use AngularJS - is there any way around the terminal?
All you need to do is to download the AngularJS source files (.js files) and get coding. I am new to it too and am fairly impressed with it. However it seems to me that is is designed for different things than CodeIgniter.
Angular JS basically moves your MVC from the back end to the front end, my limited experience tells me that it is for simpler apps than what CodeIgniter would be for. You can certainly still have some logic in your MVC back end, but the idea is that Angular becomes the application and you use a back end primarily for data storage.
There may be a way to mix the two together by making limited scope Angular pages that are worked within a superstructure of the CodeIgniter MVC, but I have not figured this out yet.
AngularJS can certainly work with Code Igniter, and you don't need to use the terminal for either.
You're probably going to want to write a RESTful API with Code Igniter that AngularJS can communicate with. Check out this article for RESTful services with CI: http://net.tutsplus.com/tutorials/php/working-with-restful-services-in-codeigniter-2/
(a little old, but the basic concept is the same)
Then, with AngularJS, you'd use $http to make requests back to the API you wrote with CI: http://docs.angularjs.org/api/ng.$http