I have developed an app in Yii2 that is as a backoffice for a Travel Agency.
I have used the basic start template, and used gii (code generator) to create the CRUDS for the models (Hotels, HotelRooms, HotelImages, etc)
I also want to create two different front-end applications (one for retail, and the other for other agencies), and I thought to separate it from the backend (maybe an angular.js app) and get the info through REST could be a good approach.
So I want to use the API Rest based on the models made with gii.
How can I achieve this?
I have read this:
http://www.yiiframework.com/doc-2.0/guide-rest-quick-start.html
and It says that I have to switch the controllers.
Currently I have (generated with gii)
class HotelController extends Controller
and reading the guide it says that I have to use
class HotelController extends ActiveController
but if I make this change, the backoffice does not work anymore.
What would be the best approach?
Make another APIHotelController that extends ActiveController?
Can I merge (in some sort of way) with the gii generated controller?
Any other way to achieve this separation of layers (back-front) ?
Thanks!
The most elegant solution I know so far to build a REST API Yii2 web app without messing up with the existent code or the routes configurations is by building a REST API as a separate sub-application containing MVC elements by itself, which means in Yii's world : as a module.
You already have a working code, accessible within the web folder, it has it's own Entry Scripts within the index.php file, its own server configurations (.htaccess file if using apache) and its own app configurations within the config folder to which your app will depend before parsing your URL's and rendering your view files within their related controllers and models.
So the idea is to create a new web folder, lets call it api for example, with its own Entry Scripts file, own server configurations, own config folder and own controllers extending the ActiveController class.
Then both, your web app and api service will share the same models files to validate, store or retrieve data.
Your app will move from this basic template based structure :
+ assets
+ config
+ controllers
+ models
+ views
+ web
...
To this new structure (from the tutorial linked below) :
+ web
+ config
+ controllers
...
+ api
+ config
+ modules
+ v1
+ controllers
.htaccess
index.php
You will need then to register your api service as separate module in order to work and being initialized by Yii.
Then you will use different URLs to get to your web app and related views or Rest api and related json/xml outputs respectively within http://[your_path]/web/controller/action or http://[your_path]/api/v1/controller/action (url structure depends on your web and api configs).
In order to implement the necessary code, here is a great step by step tutorial. It uses the basic template structure and follows yii's api versionning approach (the v1 folder).
Related
Application is being built using .Net 5 MVC & Web API. Application has a plugin system which is organized as below.
[Starting MVC Application]
|__MainLayOut
|__Modules
|__Plugin1
|_Binaries (Web APIs, MVC Controllers, logic, db access local to this plugin)
|_Views (has shared, _viewimports etc.. local to this module)
|_wwwroot (has static files local to this module)
|
|__Plugin2
|_Binaries (Web APIs, MVC Controllers, logic, db access local to this plugin)
|_Views (has shared, _viewimports etc.. local to this module)
|_wwwroot (has static files local to this module)
As you can see plugins are self contained (ex:- if you delete a plugin directory and restart the app) Any features related to that plugin will not work. (Also you can just zip the entire plugin directory and deploy it with some config file changes) Common features like User management/ Permissions etc. are provided to plugins via the main app.
As of now UI is rendered from server and WebAPIs are being called by the MVC Controllers and MVC controllers talk to Web APIs which I don't want to do when I am actually going to develop the final app.
My problem is I can move the UI part and do it as an Angular/React app. but then I can't use the plugin system that I have now. If I can do that, I should be able to break the angular/react components to different physical locations (plugin directories) and then be able to distribute those independently so that upon deployment client app will identify plugin related angular/react code and then load/run as necessary.
I couldn't find such example out there. They all have a separate Angular/React app. The other option I was thinking is to use RequireJs and AMD pattern where I can modularize my javascript code in different plugins. Main UI rendering will happen at server but client will take care of WebAPI calls getting data and binding. However this will not give me MVVM change detection which can be very useful.
So can I use Angular/React in such a way that I don't create a separate app, but use angular code in the existing app, create angualr/react modules in different plugin directories and get them to work together?
I am trying to integrate Angular with Django. I have 2 approaches which one is the best way:
Build a separate angular app and serve it's static files to django to render. In this way the routing and rendering everything will be handled by Angular.
Or to build templates in django using Angular directly and use MVT architecture of Django only.
Which is the correct way from architecture point of view? If not these two please suggest any good approach.
I'm not using AngularJS (actually I'm using VueJS but it's kinda the same) but here is what is usually done :
You do your models as usual, using Django. It defines your database structure.
You build an API that exposes your datas. For that you can use DRF (Django Rest Framework) for a REST API or graphene-django to build a GraphQL API)
You code components to build pages. And you retrieve your datas to display from the API.
For my project, I personnally use :
Django
graphene-django for a GraphQL API
Apollo Client to fetch data from the GraphQL API
VueJS for the frontend components
There are lots of tutorials on how to combine all of these so I guess there are some for AngularJS too.
You should be able to do something similar with AngularJS.
Finally, it is more like the first approach that you described. You'll have some build step that will create a bundle of files with a index.html or similar. The thing to do is to tell Django : "Hey, for any URL, point to that file".
Note that the thing I'm describing is for building a SPA (Single Page Application).
I have recently worked in a pure Scala-Play application and later in a pure AngularJS application. I'm very impressed with both and I'm wondering what is the sweet spot of combining the two frameworks together. Since the two frameworks can be complementary but also overlapping in different areas e.g. MVC and page routing, as far as I know these are some of the possibilities:
Single Page design, use AngularJS MVC-only and use Scala-Play as "dull" service layer backend with no full page refreshes.
Allow page reloads and each page reload becomes a different AngularJS root application. This seems quite flexible e.g. the client side is not bloatted with so much data for larger applications but better partitioned for the different use-cases. The downside is that I'd need different AngularJS MVC applications and I'm not even sure how to organize it as a project. Are there examples of this?
Typical server side Web App, use Play MVC-only and AngularJS for handling UI models for each separate page.
My choice of IDE for these types of architecture would of course be WebStorm but unfortunately I can't have all client-side (AngularJS and JavaScripts) and sever-side (Scala-Play) codes in a single project.
I believe that there is no the ultimate optimal architecture for combining Play and Angular. It depends on the specificity of the project, team etc.
The decision to develop UI part with Angular and the server side back-end with Play is very reasonable. Technically it may be done as following:
Development:
Both parts are developed as detached projects with the preferable IDE.
The client should have some entry point HTML page. It is reasonable to name it index.html, but is may be any other name.
For client-server integration do on the Play side as following:
Select a sub-folder under the play application root, which will serve as the "home" for the client files. The default solution is to use the folder public, since all files under it are automatically deployed.
All client files should be copied under the public folder. The files may be organized in any structure.
Add a route for the default URL as a route to the index.html. The argument path in the route should be the full path of the index.html relatively to the application root.
If index.html is directly in the public folder, the route is like this:
GET /defaultUrl controllers.Assets.at(path="/public", file ="index.html")
Add routing to the client files:
GET /*file controllers.Assets.at(path="/public", file)
Now the distribution package will include all the client files.
Putting of the client files into the public folder should be done automatically, for example by organizing the client directory structure and appropriate configuration of the client IDE.
You can find more examples in this post.
I have an ASP.NET MVC project that will have an Angular SPA inside it. At first, I decided to create a new Area for the SPA but then I realized that I'm not going to use any Models or Controllers inside the area but just JavaScript files. So, now my idea is to place all the scripts for the SPA in the main ~\Scripts\ folder of the ASP.NET MVC project but inside another folder ~\Scripts\MySPAName\ and load the SPA just trough a ASP.NET MVC View.
What's the best way to structure a project in this scenario?
Well, if you want to create such kind of project I suggest you use MVC + WebAPI + Angularjs. You really need only 2 MVC controllers: Account for all login/logout logic and Home with only one simple method Index This Index method returns view which contains only one line of code - div or section or whatever you want ng-view attribute. This will be your main application page. Why its better to use WebAPI? Because these controllers works faster than MVC ones and WebAPI provide you with great REST possibility. What bout project structure. I can suggest you my personal structure of MVC + Angularjs project:
So you have API folder for WebAPI controllers, standard Controllers folder for MVC controllers. In Scripts folder you have separate folders for your angular controllers services ang general libraries and one .js file - its your angular module and application file. Moreover, its better and cleaner if you have additional subfolders in Scripts/Controllers folder so you can split all you *.js file by category (e.g Home, Mangers, Prices etc). Also you can see that I have folder Templates in root of my project. Here you can place all your html files which you will use as angular views/templates. And I also suggest you to create additional subfolders here as in Scripts/Controllers subfolder for better and cleaner structure
Hope that will help you
ASP.NET MVC is better suited to traditional web sites. For a single page app, use ASP.NET Web API instead. Here's a tutorial:
http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/build-a-single-page-application-(spa)-with-aspnet-web-api-and-angularjs
In this, There are two web projects, one is or web api and another one is for client web page (SPA).
You just need a empty web project to start an angular project.
Index.html - It is the main html page for your application. All other pages (partial pages) for your project can be placed Inside the directory Pages.
Scripts - All your js files can be placed inside this directory. You can differentiate all your js files into it's sub-directories.
I have an existing webapp built on Laravel. I am moving to an Ionic build to create the native version.
How would you suggest I separate my views, and how do I call the routes? Has anyone any example.
Here is what I am about to do:
1. move all my views to the public folder
2. install Ionic in the public folder,
3. Using UI-route & Angular make $http calls to the backend.
Thanks for your input :-)
You can't simply do that.
If you have a "classic" Laravel app with blade templates, what you need to do is to expose an API from it.
Then you create an ionic app in a different directory (they are not related, so you don't have to mix them). You just need to develop your ionic app like any other ionic app. Then in your factories where you do the request to your API, you do something like:
$http.get('https://example.com/api/foo')
Where example.com is the domain of your Laravel application (You are going to need to activate CORS in it).
You just can't simply create an ionic app inside laravel, because that application will be built into an .apk to be installed on the phone and you can't add Laravel inside the package.
So the TL;DR is having your normal Laravel app where it lives, add it some public API so your ionic app can access it and then build an Ionic app from zero that will use that API.
It depends on you, but I prefer to keep the ionic project nested in /public, since I want a single-project app, the sources are clearly separated by being or not in the subfolder, but it helps your productivity, benefits are:
Single source control: Single source set for source version control (GIT, SVN, ...), so when I work I can do a single pull/checkout and push/checkin
Single app to deploy: Single domain, no cross-domain problems, single deploy via FTP is available, any standard php server can handle it with a single and standard account to handle
Coherent project without interdipendencies: I do not want to split logic dependencies of the same model between many projects, when I change something in backend or frontend that involve the other side, I want to have in the same project all the sources to update. It make not sense to have to go to a different project to adjust compatibility, it would be uselessy messy