I'm currently building a web app using Laravel 5.1 and would like to start creating a native application so that my users can use their phones. I have decided that using the Ionic Framework is likely the best approach for the app and just have a few questions on marrying the two together.
I've got routes in Laravel that looks like this example:
app.dev/geckos - This is a GET request.
Which takes the currently authenticated user, uses their ID and fetches all geckos that match their user ID. It does return a blade view however.
I assume that when working with something like Ionic, the GET request would need to return JSON instead on order to loop through properly?
Is there a way that I can alter my controller to serve JSON based on if the route was something like this instead:
app.dev/api/v1/geckos
Both routes would use the GeckoController#index method, ideally I just don't want to repeat the code.
I'm fairly new to Laravel and very new to Ionic. So if I'm over complicating this theory please let me know.
Any information is appreciated on this,
Andy
Another solution which I used is to have 1. application in Laravel, which is a RESTful JSON API. Then you would have 2. Web app (in AngularJS) and 3. Mobile app in Ionic (which is based on AngularJS).
So you will create two separate applications, mobile and web, which both communicate with the same JSON API. The web would be a single-page AngularJS application, so that way you can reuse all the Angular services which communicate with the API, maybe even some controllers between your mobile Ionic and Web application.
You will save some time when creating two separate responses for mobile/web application, since you would create only one: JSON response. AngularJS will take care of rendering in both applications, that way you won't have to create separate templates for web applications in Blade, instead make all the rendering using Angular in both applications. There will be some nuances in rendering of the same content in Web and Mobile app, but it would only require creating separate js directives/css styles/html templates for both applications, using Blade you wouldn't be able to reuse any view related code between applications. Also you will be able to use the same Authentication method for both applications.
To sum up, this solution should be cleaner then your solution because you will be able to reuse backend entirely between the applications, reuse a lot of fronted stuff (like input validation code, services, filters,..), reuse Authentication and introduce looser coupling and have much clearer structure then the ugly response type switch in controllers.
EDIT:
So this can be a rough example of the structure of such project:
1. API - REST in Laravel, returning JSON
-Controllers
-Session // actions CREATE, DELETE
-User // actions CREATE, VIEW, UPDATE, DELETE..
-Gecko
2. JS application - Angular App, for both mobile and web app
-common //controllers, services, filters - most of the frontend logic which reusable between both applications
-controllers.js
-services.js
-filters.js
-mobile //this part can be hosted on some server or part of the mobile application
-app.js //separate configs for mobile app
-controllers.js //controllers only for mobile app
-directives.js
-web
-app.js //separate configs for web app (links to HTML template URLS,...)
-controllers.js //controllers only for web app
-directives.js
-services.js //or even services only for web app
3. WEB APP
-HTML Templates - bunch of static .HTML files
-Home
-Login
-Register
-Gecko
-Gecko Views...
-Some index file with layout template, which includes everything from js/common and js/web, entry point to your web application
4. MOBILE APP
-www
-index.html // must include everything from js/common and js/mobile
-templates
-Gecko
-Gecko Views...
But the structure may vary significantly, depending on what part of mobile application you want to have hosted on web server and which should be available offline, or how you want to host it, how detailed the structure might be..
Doing this would be messy because your single controller action will be returning two totally different responses.
However if you go down this route, you could add an additional header to the request from the mobile app, and then check for this to switch the response.
Related
I have an application in which UI is rendered on the server-side using Thymeleaf and the backend is in Spring Boot.
Now, we have a requirement to combine this application with another react application. So, it should be like micro frontend architecture.
For this, I am evaluating the framework Single-SPA and seems like a good option when we have separate frontend projects and we need to combine them in one.
Is it possible to integrate the existing SSR pages with Single-SPA?
This should be possible with single-spa-html as long as there is no JavaScript that is dynamically created. Another limitation is that single-spa-html doesn't process <script/> tags due to browser security. If your application can meet those requirements, it should be able to interop with single-spa-html.
single-spa-html allows providing a template asynchronously, so a fetch or ajax call could retrieve the microfrontend template from the backend. Then the corresponding JavaScript is included in the microfrontend instead of script tagged in.
You can also see an example of enhancing a static html mfe with JS here: https://github.com/filoxo/single-spa-html-with-js-example/
Note: I believe we discussed this on the Slack channel but I want to share here for the benefit of the wider single-spa community.
I've been studying the difference between single page apps and multi page apps, and I think I have good view how they differ. Single page app starts by loading a single html page, and then it does never again fully refresh the page or override the original, unless the application is otherwise refreshed (browser refresh etc.) For example, the angularJS seed project: angular-seed has an index.html file. This file is the single page, that the server would send to front-end, and after that, all the other (possible) pages will be send asynchronously under the hood by using AJAX. So if you create app just with the angularjs seed, it is always going to be just a SPA application, am I right?
How in practice would you then create a multipage application with angularjs? Wouldn't you need multiple angularJS applications then? Would you have to have a separate routing for each of those angularJS applications? And why would one want to make multipage application for angularJS? Because one could always use the first index.html just as a shell, without real content, and then have separate container-pages for different pages. Could it be said that angularJS multipage app would be an application, that would just contain many SPA angularJS applications? In SPA, can you use the browsers' back-button, in order to go back to last view?
Yes, you've got the idea of SPA and MPA right.
Angular.js enables you to create SPAs but does not force you. In an MPA, I would not speak of multiple Angular applications since you would have just spread Angular.js modules over multiple HTML pages. The page flow or routing logic would then be in Angular.js controllers, in plain hyperlinks or in the backend on the server.
There might be reasons to not put a whole application under Angular.js. Maybe the authentication part of a web application might be Held separately for some reasons...
In SPAs you definitely can use the browser's back button. You just have to implement that somehow. Twitter solves this Problem by coding the state of its web application into the URL - if you're using Twitter, you might have noticed the symbols (#!) in the address bar.
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
We are trying to create a portal type application with multiple / independent "sub-apps". Assuming that all sub-apps are written in Angular what is a good pattern to achieve the following goals.
Each app can be developed and deployed independent of each other.
They share a common authentication service, they can share common libraries (directives, filters etc).
Only one app will be visible and active at any given time. The scope of each sub-app is isolated from each other.
When the users goes between the sub-apps, the state is maintained as long as the user does not refresh the page or visit another static link. (I think this is built into Angular and no special effort maybe needed)
Each sub-app will have more than one views (it will have its own menu). There will be a top menu based on what sub-apps are available. Ideally the top menu is dynamically build based on what sub-apps are deployed. Maybe there is a server side component to this (the server detects the folder structure etc and determines what apps are deployed and injects the necessary js code into the page).
Given the fact that AngularJs does not have multi-level view structure, I was thinking of using multiple ng-app declarations on different divs and then using $window scope to store the key of the active app and hide the ones which are not active.
There is no easy answer to your (rather open) question, but regarding the $route and ngView limitations, I have been having great success employing a technique derived from this: http://www.bennadel.com/blog/2420-Mapping-AngularJS-Routes-Onto-URL-Parameters-And-Client-Side-Events.htm
This is something that I also have been thinking of trying to implement. While I don't have a complete working solution, I believe that this type of portal app would consist of multiple angular apps on the same page.
The portal app would be the traditional ng-app directive on the main page and the "portlets" would be dynamically created and manually bootstrapped angular apps on a sub view div. You can share data, state, authentication, personalization, etc from injecting the portal services (contained in their own module) that provide these features into the manually bootstrapped portlet apps.
The tricky part is how the portal app would discover the portlet apps and serve up their angular modules knowing that these apps would be independently deployed web apps with their own urls.
I still have some questions around if the service data would be common between the apps or if you would need to try and leverage HTML5 local storage via the portal service (like a data manager).
I am currently looking at implementing YUI 3.5 pr1 (and then the final version when released) in a fairly large application.
The backend is built with PHP and MySQL using a MVC structure with a front controller pattern. By it self, the server can process URLs (http://mysite.com/module/submodule/option) etc and return a fully rendered page.
I would like to implement the App Framework in YUI across the whole application so that javascript-enabled browser will effectively have something like a 1-page app with history management avaliable.
I am currently looking at the app framework docs on the staging site. Unfortunately, the docs aren't complete (in particular sections on routing coordination with server and progressively enhanced apps).
In any case, if a user visits http://mysite.com/modules/submodule/option with an HTML4 browser (all versions of IE), and he has javascript enabled, he would need to be redirected to http://mysite.com/#/modules/submodule/option.
Is this something that's built into the App Framework? I would prefer to utilise a solution that does not require the whole page to be rendered out and then redirected to the hashtaged URL and then rerendered again.
Finally, I have watched the intro video on the App Framework and it mentioned that they are using the Handlebars template engine. I am using Twig as my template engine on the server side. Is it possible to use an alternative template engine with the app framework? In particular the twig js engine.