I'm planning to build an restfull api with laravel 5 for a client because they also want to make apps in the future (first ios/android, larer ios watch). For version 1.0 they only want a webversion of the site, so i'm planning to do that the traditional way with blade templating and laravel routing.
Are there good practices for combining those 2? The api routes will in some places be different then the routes i need for the 'normal' webversion, most of the services and repositories would also be the same. Output would to totally different because the api needs to return Json, where the 'normal' webversion would return Html.
Any ideas?
I would really consider not using Blade and using a front-end framework instead such as Angular. If you can get to the point where your back-end is solely serving up JSON responses, it would make your life much easier down the road.
As an added benefit, a single page app would also be much more usable on a mobile device out of the box.
You could also look into PhoneGap as well. If you have everything running on Angular, it shouldn't be too difficult to port it over to PhoneGap.
Related
I want to create an new app and for this purpose I've chosen laravel. So I'm also new to laravel.
I want to integrate an API from the beginning for things like browser addons or mobile apps. Of course I don't want to make it an API only app. I'll still need normal views and controllers which will handle this. Now I'm a bit confused about the proper structure. It should output the data as JSON when it's an API request, otherwise as a normal view.
What would be the best way to achieve this? All tutorials are based on API only apps which doesn't help me.
Is it good practice to make UserController.php and ApiUserController.php? Or UserController.php and a subfolder structure like API/v1.0/UserController.php? Wouldn't I repeat things often with this kind of structure? I mean often the only thing changes is the output, isn't it?
Thanks in advance!
Your API should be served on API routes, those can be in the same controller as the other user stuff but they really don't have to be.
I like to use an ApiController with all the API functions in it. In that you can implement stuff like "showUsers" and have it return User::all() or User::paginate(50). If you directly return a Model in Laravel it will output as JSON by default, which is pretty convenient.
Now for some real API goodness, I love using the API package by dingo in combination with artdarek's Laravel OAuth 2 wrapper. It providers really high quality secure API with lots of functionality, like rate limiting and scopes and all that cool stuff.
Dingo's API package
Artdarek's Laravel OAuth wrapper
You really don't want to use RESTful controllers for an API, since you probably want differently named endpoints. I like to keep all users at api/users but single users at user/USER for example. It's just what I prefer, my API should be totally customizable and routable in my opinion.
I recently started to build a large social network, and and I thought my structure was good but it turned out I built this logic up badly.
I mixed my views with AngularJS (bad idea), skipped blade extension, but since I'm using a lot of block and sidebar includes it became a pain in the butt.
Currently I am just handling form validations with angular, but actually all of my site pages will require ajax, data pulling, etc.
I was searching around the net and I saw that angular views are stored in the public folder, but since all my pages will use angular is it a good idea to store all my views in the public, and just use Laravel as a back end?
I know this is a silly question but I'm confused a bit.
Any help hint appreciated.
There are two ways to combine these frameworks:
Only client-side rendering
This is the easier way and used by most web applications. In this case you would use Laravel as an API endpoint which will return JSON. Angular can query this data through its $http or $resource service and compile the templates, which you store in the public folder. Angular templates are just HTML with directives and some {{var}} statements. This way Angular does all the routing too.
Server-side and client-side rendering
This is the harder way where Laravel would do the routing and compile some templates on the server-side. You would use Angular only for some interactions on the site in a way you would use jQuery for example. The benefit of this approach is performance as users will get the full HTML the first time they visit your site. The disadvantage is that you may have to write some logic twice and can’t use some of Angular’s features.
To actually benefit from most of angular's features you should write a Single Page Application. This means you will communicate with the server through web APIs and you won't have any Laravel server-side templates.
So yes, you should write two decoupled applications. One client-side, using Angular and one server-side that exposes a web API, preferably RESTful.
This way you could switch from JS/HTML/CSS on the client side to Flash or Silverlight or something else and from Laravel/PHP/MySQL to .NET or NodeJS or Meteor/MongoDB.
Sergiu is correct, but in some cases Laravel still offers benefits that cannot be achieved with client-side templates. This is related to SEO and WCAG (accessibility).
AngularJS renders content by way of DOM manipulation so search engines cannot determine what content is shown after those manipulations are complete. This is also the case for screen readers. For this reason some content must be delivered by way of server-side view constructs. That is why Wordpress and Laravel have long and healthy futures.
On the back-end or in cases where SEO and WCAG are not important, data binding client side templates such as those used with AngularJS and Ember will be used increasingly as more developers learn how to use them.
In terms of whether to use AngularJS or Laravel for view constructs it would be best to learn how to use both and apply where most appropriate.
I have given the new project to complete where i have separate components which talk to each other via services calls
They are not linked directly.
The technical head wants to build the entire frontend in ExtJS or jquery and then use JSON to load the data. I mean all forms , login etc will be JSON.
Now i ahve not done anything like that that. I mean i have always generated forms , data from server side controllers and views. like PHP or Django python.
I want to know that is this way good or achievable because i don't want to chnage things after spending time initially.
but is its the good way then i can start with it
I'm working on a Django project for the past six months, where I'm using Django for the backend service, returning only json responses, and the frontend code is completely separate.
jQuery by itself would result in unmaintainable code, even on a smaller scale, so you definitely need a high level frontend framework. I settled with Durandal.js, which includes:
Knockout.js for the ui bindings
Sammy.js for view routing
Require.js to modularize the code
I think it was a good choice at the time, and I feel very productive with that tech stack. If I were to start from scratch again, it would be very likely a similar stack.
As for ExtJS, it's a component/widget based framework, which philosophy I don't very much like, I saw the future, and it wasn't written in ExtJS :)
Although I see AngularJS and EmberJS as the titans that will very likely win the battle of frameworks, at least for now.
Maybe it's not a real question, rather is's a discussion. I decided to learn angular, using a simple task, build a blog system. And i have a few questions.
Lest imagine that the php app will have the MVC structure, so i have some questions:
Should i build my back-end only as RESTFUL app, and use json response\request upon the angular and php?
What about the view in php app, i should use them with ng-init?
Routing, server side or client side?
What about caching?
And the last, but not the least, where i should put the logic about data that user will input?
Can someone give me the instructions or directions, about this things, and maybe useful link's to read the articles, to combine the php and angular, or maybe i'm doing it in the wrong way?
You might want to consider this type of application as actually TWO applications.
The first is the backend, the API. You can use your PHP framework to build an API that will allow you to have data persistency, validation (business logic), etc... and forget about the front end for now, you are only building an API for the backend data.
The second part of the app is the AngularJS frontend. This includes all of the views and everything that the client sees. None of that is coming from the backend.
This allows you to use the backend API (the PHP bit) to act as the data store, with it's own validation for safety, while having the seamless user experience and basic client side validation from AngularJS.
Routing is AngularJS, as that is the actual frontend that the client is using.
Caching can be done (if needed) in the backend, your API.
Validation will happen in both the frontend and the backend, although they can be slightly different if need be.
Remember, you build the backend strictly as an API, without consideration for the frontend (as if there will be more than one app using it), so it will have it's own validation rules and logic.
Hope that helps.
I have found a very simple structure that allows me to utilize Angular with PHP and restful api's. I use Angularjs for all views. I use a restful PHP API framework called slim to facilitate the communications between Angular and the PHP models which I use Doctorine2 for.
85% of my coding is done with Angular(Views). 5% done with the API(controller) and the remaining 10% configuring business logic in the Models. Great separation of concerns and not much overhead. Simple and concise.
So I have decided to take a project I have been working on, and project management system, and convert it from a standard multi-paged application to a single-page application. In the process I have looked at a number of javascript MV*ish frameworks (ember, knockout, backbone, etc...) and have decided to go with backbone.js as it seems the most flexible solution and that I already use underscore.js for both its utilities and template system.
The one biggest concern I have with doing this is the potential code duplication I am going to have for model and business/domain logic in both my PHP models and in my backbone models.
This is just a technical cost I have pay when going with an architecture like this or are there some things I can do to lessen this concern?
You may want to take a look at a previous question I answered involving Node.js:
Reusing backbone views/routes on the server when using Backbone.js pushstate for seo/bookmarking
What I'm currently doing right now is using Davis.js + Mustache + Java Spring MVC backened (based on my original question: Single page Web App in Java framework or examples?).
If the browser does not support Pushstate then I have the server do the entire rendering of the page using a Java version of Mustache (ie standard Web 1.0). If the browser does support Pushstate then the browser will make an AJAX request for a JSON version of the model. The model is then rendered client side use icanhz (ie javascript mustache).
This works fairly well if a large part of your logic is getting a model an then rendering it based on specific URL. That is your business logic is "based on some URL I'm going to render this". This is how most of the sites on the web work (including this one which is still rather web 1.0). Obviously this would not work for say something like real time chat or HTML5 game.
A python version of this design is mentioned here: http://duganchen.ca/single-page-web-app-architecture-done-right/
I'm sure someone has done a PHP version.
If you are using different languages in server and in client I think there is not possibility to avoid this partial logic duplication you are concern on.
If you definitely want to use same code in server and client you have to move all of it to the only common language: JavaScript.
There are multiple JS frameworks those integrate very transparently the development between server and client: derby, meteor, ...