So this past year I have dived into professional web development using laravel, and the journey has been amazing, with stackoverflow helping me tremendously. This question is more of an opinion rather than me asking how to do it. So, I'll break it down with an example.
Suppose I am creating an articles website. For the articles, I create a migration, model, controller and then views. For migration and model, it only requires one set of it because only one table exists for it. For views I have separate folders for admin panel for backend and frontend. Usually in the routes I'll create a group for backend with prefix of admin and auth guard which comes built in with laravel, though in the newer versions of laravel you gotta do composer require laravel/ui. Now, because I have different routes for both backend and frontend, logically what I do is create a completely different Controller for the backend with all the CRUD functionality, and for the frontend I make a separate controller and put index and show function in it.
Is this the best way to deal with it, or is there a more efficient way of handling the backend and the frontend? Also, is the basic workflow of development usually the same as I have mentioned, or do you people have a different take on how to do these things. Please let me know.
Cheers :)
In most projects, frontend and backend, are two different environments with different needs, so using the same controllers would be inappropriate as it might lead in complex - no-clean code.
What works for me best, is to separate the controllers in the following groups:
Frontend
Backend
API
In some cases you might also need a group for the controllers handling the ajax/async requests, i.e. Async group.
Related
I want to build a project with 3 section: API, Admin, and User.
I will build the API using Laravel, Admin and User will using ReactJs (SPA) with this route:
api.example.com (api)
admin.example.com (admin)
example.com (user)
I need a solution about project management.
Is it better to separate those 3 or should I combine it into one
project (laravel)?.
What about teamwork if I combine or not?
Any drawback if I combine or separate those?
Thanks!
Unless you have overlapping functionalities, I would suggest that you separate the three with three different projects.
The benefits are:
One project breakdown will not affect the other
You can have separate developers working on different sections and they won't have to worry about conflicts/commits not pertaining to their code
It will help you create separate documentation for the three, which will be easier for someone new to the project
From a security perspective as well, if one application gets compromised, the others won't be
However these also get influenced by personal experiences, and specific project requirements. Experience is the best teacher.
So basically, I have this project I'm planning. A kind of "social network".
I was just wondering, as for now, I have a single controller (ProfilesController) wich takes care of status updating, profile editing, gallery uploading / viewing, settings etc.
Is this a good structure? Or should I separate it into different controllers like (ProfilesController, GalleryController, SettingsController, GuestbookController)?
And my models, I currently have Guestbook, PhotoAlbum, Profile and User models. Is this good? Or should some of theese maybe be merged into User or Profile?
Thanks in advance.
I think to keep things as RESTful as possible you should have separate controllers for the separate models. Your models should definitely each be their own files/classes.
1. Following the principle "single responsibility" okay that you create a controller for each process.
2. Laravel each table (that you used in the project) of the database must have a Model.
3. If you want to do good things would recommend to follow the principle "first API": Designing the structure of your API and then begin to program it. Having done this, recently begin to develop interfaces and your processes using your API.
I would stay with REST and really create For every table, a model and a controller. So you can develop your application in a very clean way.
If your "social network" or whatever application you want to develop will get bigger and more complex, this is the best way to keep it clean and clearly represented.
Once I started a small Project and was not really caring about following this principle, but you will get to the point you regret it.
So start your Project with a clean structure and create for every Model a Controller.
I recommend to also use the Route::Ressource for defining the basic routes. So you follow all the conventions.
Route::resource('Model', 'ModelController');
For more informations, check the docs.
I've 3 projects and the mostly need the same models, and the data. So I'm thinking to create a Core app that have Core models(User, Store, etc.). And create different apps for each project. Besides they use the core models, they can have their own models. So what's the best way to do this?
I left this as a comment but it is a potential answer to this question.
Original comment
You might want to look into an HMVC package for Laravel. The only decent use case for it is multi sites using the same core code. This would let you have multiple sites with a core code base using internal cross controller requests from the site controllers to the core code
HMVC or Heirarchical Model View Controller, as a concept extends the MVC pattern and allows developers to make cross controller/route requests. In theory this would allow for x number of sub installations of Laravel (using a package like this) to call a single common ancestor application that would provide them with an API for dealing with specific requests.
This is good as it provides separation of the api/master app and its child application instances, leaving them free to implement their own logic.
I think this may be something that would help you in this instance (and isn't difficult to use).
We are building a intranet web application in PHP with CakePHP.
However we have barely experience with CakePHP
Our Intranet will have two user portals.
Employee portal
Client portal
Both portals will use the same data but have their own user interface.
Employees can see other data than clients and vice versa.
We want to build a central core for both portals. For example, a single authentication system, a contact form, a notification functionality, same footer information, etc. We want to use this central core as much as possible so we don't have to rewrite code.
We use Git to manage our code. We want to make a branch for both portals and one for the shared core.
We hope you can give us some advise about how setting this up with CakePHP.
Is building multiple app's a good idea?
Or should we just run CakePHP and our core on two web servers? (one for each portal)
Or should we use plug-ins for the core functionalities?
Or should we use single controllers with multiple views (one for employee and one for client?)
Or something totally different?
Thanks for any advice
Eventually, you'll start noticing similarities between the 2 portals, and the code-base. If they are sharing same data, why don't you have a single code-base and have permissions around what users can see based on roles? We had to do this recently when we merged 3 pages into 1. 1 page was for admin, and the other 2 was for other roles. Then users started requesting features on page 2 that page 1 already has etc etc. it became a mess and we decided to consolidate these pages into 1, and have permissions around what each users can see based on their roles. Also read more about helpers as it will come handy, so you dont make your view bloated.
In my experience a portal is typically a very thin layer on top of some CRUD framework. I think the opportunity for code sharing between these two applications is very limited. You can share the authorization and authentication .. and that's about it and I don't know if sharing this part is a good idea (probably not).
If most of your code goes into building the HTML views you'll likely end up with two completely separate views for employee and client.
As Ayo mentioned... the permissions alone will separate the two user groups and you can take advantage of CakePHP's layout or the themes feature to give a totally two different look for each user group.
You may also want to take a look at CakePHP plugins feature. It allows you to easily add new functionalists to an existing app, without messing with the existing code base.
I recently started with CakePHP and so far I'm loving it, specially the scafolding and bake.
I'm building a webapp that will manage applications to companies. (i.e., where have I applied to, with whom have I spoke, the status of the application(s), how long ago has it been since I did sent/recieved a communication regarding this application.)
I have a model Application and an Action model. An application has multiple Actions.
When you add a new Application, it does not make sense to add "just" the application but to add one action. Is there anyway to have my applications add view to connect with two controllers and add the action and application simultaneously?
Please do let me know if my problem is understandable or if you need further clarification.
Thanks.
Yes, you can. See this question.