What's the recommendation on grouping your business logic in Laravel? I find Laravel to be quite messy when it comes to large web applications. Should we continue to use Laravel default file locations or have anyone tried using a modular package like https://github.com/nWidart/laravel-modules ?
Laravel is a fantastic platform, not only for its elegant syntax and rapid development tool, but also for its community and open source packages. These bundles go a long way toward reducing development time.
Modules
Modules are like packages in that they have their own Models, Views, Controllers, Migrations, and other classes.
All Controllers and Models are placed in the app/ folder by default in a Laravel program, while Migrations, Seeder, Providers, and other components have their own folder.
These folders become inconvenient when the application develops. It becomes difficult to locate logic for a specific portion of the application.
This is where using a modular approach to large projects simplifies production and maintenance. You can build different modules for different parts of your application using Modules. Each module has its own set of configuration options, such as controllers, models, views, migration, seeders, and providers.
To use modules in Laravel, simply autoload the Modules folder using PSR-4 and you're finished. However, this will entail additional tasks such as registering a namespace for language, views, and configuration, as well as running the migration.
Laravel Modules
Installing Laravel Modules is similar to installing any other
package.
Laravel Modules provides Artisan Commands to create new Modules,
activate/deactivate modules, create migrations. Below is a quick
screenshot of the different artisan command it provides.
When you create a new module it also registers a new custom namespace
for Lang, View, and Config.
Lang::get('blog::group.name');
#trans('blog::group.name');
Apart from these it also provides useful Facade Methods, Module
Methods
And also can publish your modules similar to a package (document).
How we used Laravel Modules?
Initially, when we started working on a pos (point of sale) application we didn’t have an idea of creating different modules.
But as the requirements increased to have a plug-play Restaurant extension for it, the idea of making modular made more sense.
So after creating and adding restaurants and many other optional modules, we added a setting for each business to enable or disable different modules.
Module::all(); method was used to list different modules the application had.
Each business can enable or disable modules for them as per their needs.
We used a combination of Module: has(‘blog’); business settings to check if a module is available & enabled.
The Module (or extension or plugin) can be put in any other application to add the functionality.
Related
We have an existing backend with microservices for our native apps. Now we need a support and admin UI, therefore my question, is JHipster the right generator for that and if yes, how can I create entities from my existing databases? Most of them are MySQL? As I understood I need a JDL but do I need to create it manually?
Thanks!
JHipster has no support for generating code on top of existing databases. So, you would probably have to write manually JDL for your existing entities, it can be very difficult or impossible depending on the conventions you used for naming your tables, columns and relations.
There's a module that can help to some extent https://github.com/bastienmichaux/generator-jhipster-db-helper.
However if you plan to generate only frontend code, it could be simpler because you would not depend on database structure. The effort for connecting your generated frontend to your existing backend would depend mainly on which authentication type its uses and REST API it exposes.
Just build a prototype: generate frontend only with jhipster --skip-server, write a JDL file for few entities and then import it, then see how you can modify code to adapt to your backend.
I'm currently learning myself the Codeigniter framework. I want to create a project that will have a front-end (which will be used by users) and a back-end (which would be used by administrators).
I have looked through different articles, all of them suggest using HMVC to separate the public and admin controllers/views. I have also considered to create two separate projects, one for the public and one for the admin, both using the same database.
I have tried to do research on which one of the methods mentioned above would be the best solution for a potentially large project, but could not come up with any sustainable answer.
Is it possible that two separate CodeIgniter projects can access and use the same database simultaneously?
Edit:
The client project would mostly just query the database for results, whereas the admin project would be full CRUD.
If indeed creating multiple projects would be the recommended way to go, the admin project would be running on a sub-domain i.e admin.example.com whilst the client project would be running on example.com
It is valid to use any of the approaches you mention. It is a matter of personal preference (read: opinion). I have used each singly and in combination with more or less the same outcome. I have settled on using none of the above. Instead, I use a single project, no HMVC, no subdomains, standard CI file structure. I feel keeping it simple ultimately makes it easier to build and maintain. YMMV.
What separates the public-users from admin-users is authentication and authorization (A&A). Nobody gets into an admin controller without the proper login credentials and permissions. You're going to need A&A anyway to keep the public from accidentally discovering the admin area. IMO, a "special" file structure and subdomains actually make implementing A&A harder.
Depending on your deadline for this project you might want to look at using CodeIgniter Version 4. It's a thoroughly modern revamp of the framework. It is still in beta test mode, but I've found it to be quite stable. They are working hard to get to the release version. There is no published release date yet, but all indications are it will be sooner rather than later.
The answer as to how to configure CI is really dependent on your needs and what you feel is best. There is no right answer or "acceptable" way of doing things in this regard.
When I first started with Codeigniter, I had just a sub-folder for backend controllers called admin as well as an Admin base/core controller that all admin classes extended rather than CI_Controller. Models/views can be similarly organized in to sub-folders. This was a perfectly acceptable solution in my opinion for small-scale applications.
I moved in to HMVC and found that it really isn't that much different in terms of keeping them both separate. Although you can easily drag-and-drop modules from different projects so long as they are decoupled, you'll still have to jump through hoops to get front/back ends separate. I believe I used this is a starting point: https://github.com/jmtolibas/HMVC-CI3-with-Separate-Backend-and-Frontend
In terms of what you mentioned, having 2 separate projects wouldn't necessarily be a bad idea. You could even share the same system folder with a modification in index.php regarding the system path. Multiple database connections shouldn't be an issue.
So basically, all 3 approach will work, it is up to you to determine which one you like working with the most.
If you want my opinion, I would use Laravel or Lumen on any new project, and separation of front/back end is rather easy with packages, namespacing, .etc.
I have application which has core website, api and admin area. I wanted to know is it bad idea to have everything in one app or should I create different Symfony2 project or should I split them into different kernels?
I'm not sure if adding lots of bundles on same kernel will effect performance a lot or is just a little bit, which does not matter?
Following are options:
keep everything on same kernel, it wont make much difference
have multiple kernel for different part of application (api, admin and core website)
create different Symfony2 project for admin area and api.
or your wise words :)
You can define more "environments".
For example :
In AppKernel.php
public function registerBundles()
{
$bundles = array(
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\SecurityBundle\SecurityBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
new Symfony\Bundle\MonologBundle\MonologBundle(),
new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(),
new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
//new AppBundle\AppBundle()
);
if (in_array($this->getEnvironment(), array('api'), true)) {
$bundles[] = new ApiBundle\ApiBundle();
//-- Other bundle
}
//-- Other environments
return $bundles;
}
}
It mostly depends on bundles quality. And this how much connected they are.
I would reject point 3 at start (create different Symfony2 project for admin area and api.) - as probably you don't build two separate applications.
Have multiple kernel for different part of application (api, admin and core website)
Common problem is created by Listeners and services in container. Especially when your listener should work only in one of app contexts (api/frontend/backend). Even if you remember to check it at very beginning of listener method (and do magic only in wanted context) then still listener can depend on injected services which need to be constructed and injected anyway. Good example here is FOS/RestBundle: even if you configure zones then still on frontend (when view_listener is activated for api) view_handler is initialized and injected to listener - https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/config/view_response_listener.xml#L11 I'm not sure for 100% here but also disabling translations and twig (etc.) for API (most of api's don't need it) will speed it up.
Creating separate Kernel for API context would solve that issue (in our project we use one Kernel and we had to disable that listener - as blackfire.io profiles were telling us that it saves ~15ms on every fronted request).
Creating new Kernel for API would make sure that none of API-only services/listeners will not interfere with frontend/backend rendering (it work both ways). But it will create for you additional work of creating shared components used in many bundles inside project (those from different kernels) - but in world with composer it's not a huge task anymore.
But it's case only for people who measure every millisecond of response time. And depends on your/3dparty bundles quality. If all there is perfectly ok then you don't need to mess with Kernels.
It's personal choice, but I have a similar project and I have a publicBundle, adminBundle and apiBundle all within the same project.
The extra performance hit is negliable but organisation is key ... that is why we're using an MVC package (Symfony) in the first place, is it not? :)
NB: You terminology is a little confusing, I think by Kernel you mean Bundle.
Have several kernels could not necessarily help.
Split your application in bundles and keep all advantages of sharing your entities (and so on) through the different parts of your application.
You can define separated routing/controllers/configuration that are loaded depending on the host/url.
Note :
If you are going to separate your app in two big bundles (i.e. Admin & Api),
and that the two share the same entities, you will surely have to do a choice.
This choice may involves that one of your bundles contains too much (and non related) logic and will need to be refactored in several bundles later.
Create a bundle per section of your application that corresponds to a set of related resources and make difference between the two parts through different contexts from configuration.
Also, name your classes/namespaces sensibly.
This is a question about web based software architecture. I am a Hybris newbie, but as I understand it, you can create a full Spring MVC app in one Hybris extension. What is the value of breaking out components of that app into multiple Hybris extensions? Are there web app features or architectural value (e.g. maintainability, extensibility, performance, etc...) that you can only realize by using multiple extensions?
Thanks!
So Hybris is based on the concept of being flexible and modular, allowing new functionality to be plugged in where needed via extensions. An extensions is an encapsulated piece of the Hybris Suite that can contain whatever you need it to contain, I.E. storefront, hMC, backoffice, etc. By default extensions are completely independent, however you can create dependencies between extensions no problem.
Say you're building an application that you want to have a section in the hMC, a frontend and some functionality in the backoffice too. In general you would have 4 extensions here:
a core extension for the model, services, interceptors, etc
hMC extension
frontend extension, pluggable frontend
backoffice extension
The real value of extensions is they allow hybris to be flexible and modular allowing for easy migration from one version of hybris to another.
I am trying to use Orchard extensible Framework as a base of my application.
I only want the framework and core modules but don't want any of the database access stuff.
Does anyone know how I can get rid of this database and configure it to not read from the database and lunch my module on startup instead of Orchard startup module
Thanks
You could (with considerable work) implement your own data access provider, but Orchard relies heavily on the database for everything at a core level: Settings, migrations, etc. You need the startup module for the Orchard context so that all of the framework and core modules can function. You would probably be better off customizing/overhauling everything on top of the core rather than trying to have your own module replace the startup module.