I needed to know which folder is more suitable to host my Rest API in Yii2 template advanced, backend or frontend.
I also saw some examples where developers created a new directory, called it "api" and programmed the API from there, but I don't find much information by developing from this method.
If you know the most correct way to do it, I would apreciate if you could explain me.
That totally depends on your requirements if it is going to be a complete full app or just a single controller with a few actions or a single ActiveController.
But a good way is to keep things separate just like you are using the advance-app and you have the backend and frontend folders so that you can differentiate the code base, and keep the code in their concerned folders, those folders are actually 2 separate applications running separately with their own separate configurations i.e backend/config/* and frontend/config/*, and can share some common configurations like database and others from the common/config/*. Same like that you can create a separate application/folder where you can have all the code base and configurations related to api you are going to build.
You can find a very good reference for adding more apps into your existing application by Yii here on GITHUB which will clear your concept about how to add more apps.
Then you can go to this article by Budi Irawan's Tech Blog which uses the advance-app to add a new application for the API. You will find the directory structure with example models and controllers along with testing them with POSTMAN.
Backend and frontend are also just a folder in the Yii2 advance app with just namespace different, they are different for our understanding, it is not necessary that you use backend for backend purpose only.
So for the API, you can use any of these folders, but it is always recommended to put thing separately like we put backend thing in backend folder and frontend things in frontend folder.
It's totally up to you and your coding style.
i prefer putting Rest API into a separate module, for instance into "common\modules\api". that way i can "mount" the api in backend or frontend via configuration. Also, nice urls are automatically provided, like /api/<controller>/<action> (where api is the name of your module).
One more thing to consider is how to update your api. in case of modules everything is well organized. you could start with "v1" and put your controllers in here, and move up to "v2" with a different set of controllers. so your first api endpoint would read /v1/users, later on you can additionally provide /v2/users.
more about modules here
read "URL Rules" here
Related
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
What is the best way to create a single page module for Yii2?
For example using Ember, I will have index.html and assets folder to publish.
I see two ways, one would be to just put the application under web accessible folder, it will work fine.
But what if i want to check access to the application using existing RBAC?
Another way would be to create a module and in default controller have something like
return $this->renderFile('#path/to/index.html');
And load all assets with Asset Bundle.
The problem with this approach is that i will not know the folder where assets will be loaded (it can be solved with afterCopy callback or something, but all this doesn't look nice at all).
Please advise.
Certainly it is a personal choice technique, since control RBAC is manageable level action and does not pose any problem. Once the controller is easy applicarre your organization's access control using a suitable configuration of the Access Control filter.
Alternatively, the fact of creating a module appropriately for these purposes makes it all the better organized and, precisely, modular, beyond the greater complexity in the creation of the various parts in play (module, asset, cofig / main.php) yii2 handles very well and automatically the assets and necessariio not know a priori in the name of the folder where I finish the specific assets (Yii2 find what they need).
However if this is not a 'module' with reusable application characteristics I would opt for the first solution
I have an existing Zend Framework 2 project. Now I've been experimenting and considering rebuilding the front end to be entirely AngularJS, as opposed to the now with Zend Framework 2 MvC coupled layouts and views. But for that reason, the models and controller with their respective routes exist and they use services that have a lot of business logic.
If I were to add an API to this existing project through Apigility, say, for external third parties to be able to access account information, how am I supposed to do that without interfering with my current controller routes?
Apigility Admin UI automaticly creates routes appending the base url (www.domain.com/[api url]). This does not directly conflict when I have an AccountController with /account routes and an API route that uses /accounts/[:accountId] but mistakes are bound to happen.
I should use a url like api.domain.com, however Apigility Admin UI adds the routes automaticly and has, as far as I have seen, no option to create a subdomain route through subdomain 'api'. Of course I could modify the automaticly generated routes every time I make changes through Admin UI but that seems like a hassle and prone to error.
While spreading my question around for an answer, someone on the #apigility IRC channel was friendly enough to give me an answer.
I was overthinking this, as dualmon mentioned in the comments. I had thought Apigilty Admin UI was a tool for managing the whole API. nuxwin^ on IRC told me that while Apigility Admin UI does automate routes for you which can be configured with a base url, it's still only meant for development time. It would mean if I were to route my subdomain to a module I could do that after developing the API.
Simple solution, I just had been overthinking that tool demanded me to follow a certain path.
I've done a lot of research and before I get into this new project I wan to ask you for opinon of arhitecture I should take.
I am creating an application that is build with multiple modules that are not connected and I want to sperate them as modules. They will be developed separately. Now I want to find a best way to create this in ZF. First idea was to just change path to zf library to external resource and put every project seperate but then session and variables that needs to be common are seprate wich isnt good. What I want is single authentication point (like sign-in on google) and then have this modules (like gmail, calendar, google search etc.).
Next idea is to build subdomains and based on them do some routing: api.example.com -> api module, account.example.com -> another module etc. I found this here: Zend Framework 2 Routing subdomains to module or here Adding sub domain based routes in Zend framework .If this is the right way wich is better?
Another idea is to switch settings in bootstrap. So if request comes from api subdomain set APLICATION_PATH to api/ else to something else. But I dont think I could use same session then.
Third is to create rest auth service and then use the second way to achive this.
Any suggestions or ideas how could I achive this?
Sei ying there is no special move that is best, it all depends, any
move could be best, its up to you when the times right, to move
correctly, accurately and with great speed...
To sum it up: you have to choose which methods are best for your use case.
Developing separate Modules doesn't mean they won't share the same session once put into one application. There are already dozen of Authentication Modules out there that are able to connect to authenticate against google, too.
If you develop said modules: "Login", "Calendar", "Gmail" and then you put them all into your "MySuperApplication"-Application, then those will share the same browser-session. You'd however make sure that each of those has the proper interfaces to talk to each other.
It's really difficult to answer your question as it appears that you do not really understand the basics of how ZF2 works, therefore my only suggestion can be to start developing and come up with real questions ;)
I have to develop frontend/backend application using cakephp.
can you give me advice how should i develop them, using same cakephp library?
or I have to develop them using separate cakephp libraries?
I am confused - cakePHP would be used to implement both.
PHP would be used to implement the server-side backend. The same "project" would also contain HTML, JS, CSS, etc that will be used to render the front-end within the browser. Any PHP "views" will also execute code on the back-end, although any HTML output will be rendered on the frontend.
Does that help at all? Or am I missing something?
If by frontend/backend, you mean an application with a user interface (frontend) and an administration interface (backend), then you want to refer to the Prefix Routing section of the manual. This will allow you to have separate flow and interfaces (controller/view) for each type of user while sharing the same data (models).
If by frontend/backend, you mean an application (frontend) that communicates with another server application (backend) using web services, then you want to look at the Additional Class Paths section of the manual. This will allow you to share common classes with two (or more) separate applications.
Note: the above links are for CakePHP 3.x, though these features have existed in one form or another since v1.2.
Not quite sure if I understood you correct, but if I did:
You can set up multiple projects using the same cake-core files. The core files don't even need to be placed in the webroot folder..
http://book.cakephp.org/view/35/Advanced-Installation
For your own sanity, you should regard the backend management as part of the same project as the frontend.
The systems I have built generally use view-type methods for the public view and crud-type methods for the admin view. How you lock down the admin is your choice. Personally I don't like the default admin prefix way. I use login and ACL - Mark Story's tutorial on http://book.cakephp.org/ is superb. With that you can password protect methods.
CakePHP is very flexible and extensible and you can make the administration as simple or as flexible as you like.