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).
Related
I'm looking into building my application as flexible, decoupled as possible.
I'll be split the application into different bundles which handles clear responsibilities.
Now to the main concern of mine, how do I actually make two or more bundles share information in a decoupled way?
I've been looking into different paradigms like headless CMS, microservices architecture etc that has inspired me.
Let's say I have a UserBundle which handles the registration and login of users. Then I have another bundle, DashboardBundle. DashboardBundle's responsibility is not to handle the users, but it do need to display a "Hello John Doe" message at the top of the menu bar.
Solutions I've thought so far:
One way I though about solving this would be that each bundle could actually provide it's own API. Meaning that the dashboard bundle would simply make a API call to the UserBundles API, asking for the currently logged user.
UserBundle would provide a UserManager service or something similar, that would be the layer between UserBundle and any other Bundle / Code needing to talk to the UserBundle.
The two first solutions would still couple together to bundles, BUT they could be developed quite independent, even though DashboardBundle is obviously dependent on UserBundle.
Is this really stupid if I want to achieve decouple, or is this actually a valid approach forward? If these are actually not crazy ideas, do anyone have names of concepts that this is called so I could read further into this idea?
you find some answer here and used design pattern concepts is a good solution for decoupeling/coupeling and other problems. But it's nice to not exaggerate and too complicate your application.
Everything in the modular system must be independent. Symfony used the EventDispatcher for this job. If you create an event in Javascript, then you call this event in a different module (Bundle). With Eventdispatcher you can build a structure like WordPress hook system. You can use KnpMenuBundle for menus. With EventDispatcher, you can add menus from different bundle.
IMHO you are mixing concepts. The should be reusable parts of your app (like user manager, connection to external services and so on that should be bundles. Then once they are bundles you decide to load them as vendor o as bundles. But the core part of your app must be in AppBundle, because that part must be the most specific for your app and for that reason the less reusable code.
So what I would do is to make the most general parts of your app bundles (or reuse existing bundles) and then a single AppBundle with the app specific code.
The general parts are injected in your AppBundle as services, or inheritance (i.e. for entity definition) and your specific part of code is the one in charge of knowing how to speak with the vendors or another bundles.
I am building a l large scale PHP Laravel App. It is an app for Developers which consists of many smaller apps/modules.
For example a Bookmarks app similar to PinBoard, a Notebook app similar to Evernote, Code Snippets app, RSS Feed Reader, and about 30 more little apps all in 1 app in which each app acts as a module.
MY question is about performance. With this many Models and Controllers, etc being loaded, can I not expect good performance on a large user base of this app?
I realize there are too many factors unknown like server settup and more but more so I am asking are things like Models and stuff all loaded on app init or only as needed? Many times most of the apps/modules will not be used in a request.
I have see some packages which add modules and the modules get there own controllers, models, routes, views, and everything that you wold see in the App folder for each module. However I am not sure I want to go that route so right now I have it all under the main app like usual.
The simple answers are yes, the app only loads the models/controllers you're using for a given request, and no, the number/size of models and controllers (including those in packages and modules) you have won't negatively affect your app's performance.
The more complex answer is, as always, it depends on how you've written your code; models calling into other models for some piece of business logic, or eager-loading several relationships worth of data without caching, or using an absurd amount of dependency injection in every single controller... but all that's pretty bad app design anyway and not specific to Laravel.
But the most impact you'll see to performance, in my experience, is Eloquent code that tries to be too fancy or inefficiently fetch data out of the database. Check out the documentation to learn about ways to avoid that:
https://laravel.com/docs/5.3/eloquent-relationships#eager-loading
I have been glancing at a RESTful specification available on http://restfulobjects.org (direct link to spec here). It is a little different from other things I have seen, but it makes sense, and having examples and clear specifications makes my development a lot simpler.
According to the standard, the URIs will be like:
api.example.com/object/user/31
api.example.com/object/user/31/properties/username
api.example.com/object/user/31/collections/channels
api.example.com/object/user/31/actions/someFunction
api.example.com/object/user/31/actions/someFunction/invoke
See this answer for a brief explanation of the structure. It is quite clear.
Note: This is not a discussion whether or not services/actions can be
represented as resources. There is a good discussion on that topic
here: http://www.infoq.com/articles/Intro_Restful_Objects. Look towards the end of the comments section.
My project is still on the drawing board, and most design elements up for grasp. I will however be using Symfony. I have my entities, and I have some services that act on those entities, and I have controllers to define what the services will do in a specific context.
And so to my actual questions:
...the Restful Objects spec is not based on the MVC pattern - it makes
no assumptions about the architecture of the server that implements
the API. In the URL:
~/objects/customers/31/actions/lastOrder/invoke
the 'actions/lastOrder' is not specifying a controller action, it is
specifying an action (i.e. a method) on a domain object (customers/31)
How do I structure my controllers in the most efficient way if I want to use the specification in an MVC application? Considering that the controllers would somehow serve different resources (objects, services, domain-types) as well as different representations of that resource. What are my layers?
Update Do I have e.g. a customer controller? An generic object controller? A useraction controller?
Do I need to rethink my whole entity/services approach? i.e. the solution for how to implement this is beyond the controller structure? (I fear it is, and then I do not know my next step)
For simplicity/efficiency I would like to make use of the FOSRestBundle and NelmioAPiDocBundle. I believe this can be done, but I then am concerned the spec will only serve as a url template for me, and not being implemented in my logic/design since I have to massage my framework to fit the URL somehow.
Please excuse my ignorance if this question has an obvious answer. I am new to RESTful APIs. If it comes down to a subjective perspective on implementation model, please give me some pointers, because I am currently at a loss for how to approach this.
From the "What is Symfony2 ?" article of Fabien Potencier:
Is Symfony2 an MVC framework?
If you look around, every single framework seems to implement the MVC pattern. And most of them are advertised as MVC frameworks... but not Symfony2. Have a look at the documentation, and you will see that the MVC pattern is only mentioned once or twice, but Symfony2 is never defined as being an MVC framework.
A bit later in this post:
Symfony2 is an HTTP framework; it is a Request/Response framework.
That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.
...
Sometimes, you just need a way to create a REST API. Sometimes, the logic is mostly in the browser and the server is just used to serve data (think backbone.js for instance). And for these projects, you don't need an MVC framework. You need something that handles a Request and returns a Response. You need a framework that implements the HTTP specification. HTTP streaming is yet another example that does not fit well with the MVC pattern.
...
And if you like to call Symfony2 an MVC framework, then you should know that Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM.
As Symfony is a set of components, you can easily adapt your usage of the framework to the project you are working on, and the principles that you want to follow (here a REST specification).
The FOSRestBundle is very extensible.
You can define your routes manually, create different views of your objects through serialization.
Plus, I think you can keep very light controllers by writing the most of your objects management's logic inside Repository classes.
So,
Use simplified models and serialization to have different views/layers of your objects.
You should not rethink your whole Entity/Services in order to be more REST, just give them some changes/improvements in order to use them through data-transfer objects/domain objects (models) and Repository classes (fetching/storing methods).
You should be able to take benefits of use REST utilities such as FOSRestBundle, it provides more than built-in actions, allows you to make all custom stuff that you could need, be MVC or not, and be REST or not. It's at your own appreciation.
Have you considered using either Naked Objects (for the .NET platform) or Apache Isis (for the Java platform)? Both of these give you a complete Restful Objects compliant restful API for free - derived entirely from your entity models. (I am responsible for the first of these two. Our implementation is built on top of the ASP.NET WebApi framework. We have a RestfulObjectsController, with many methods on it, but these are all generic methods, corresponding to the various Restful Objects resource types - we do not need to add any new methods specific to the domain objects or their actions.
i just followed this docs api rest phalcon and it worked!, but i don't know how to properly set more resources like robots in the example, if i have 10 resources i don't like to have them in the same file.
using router?
Thanks a lot.
If by resources you mean models and if it works as is, you can simply create more models in my-rest-api/models/ directory. Normally you'd need to configure an autoloader, but micro apps probably know where to get models from.
If you are asking how to make your app better organised you probably need to move away from the micro app and take advantage of the MVC pattern. If in the example you worked with a single model and all related logic was handled in a single file, with MVC all logic is organised into controllers. Normally single controller handles logic related to a single model or models related to it. The official tutorial explores this in depth with further references.
Edit:
And as Julian himself pointed out Phalcon\Mvc\Micro\Collection is another approach for micro apps.
I am busy on a project that involves calling the API's of nine other sites. This number is expected to increase in the future and the actual method of API will differ (SOAP or XML).
There is a specification that each site needs to be modular so that my client will be able to sell them our API (which they can then give to other aggregators).
I've completed a number of Cake projects in the past but all of those were database driven. Can somebody advise what the best way to approach this would be?
At the moment I am thinking of making each API a plugin. I will place the API calls into a model (not attached to a database table) and then the rest will follow naturally. Because the actual views of each API will differ I won't be able to use a common controller or views (each company API we consume has different business rules).
Can anybody tell me if this approach sounds reasonable or if I'm off track?
Thanks,
Andy
Maybe in your root application you could extend AppModel. A SoapModel for Soap-based API calls and RestModel for REST-based calls, etc.
Then in each plug-in, you could make the model extend the appropriate class for the basic communication, and then you only have to handle the site-specific business rules in those models. This extra layer of abstraction would nicely hide away the WS implementation details.
You don't even necessarily need to split these into plugins if you're going the fat model route. Plugins are only particularly useful if you want to self-contain a "sub-application" of some kind and make it re-usable across other Cake applications.