I'm planning to create an application with Laravel 5.8 that's going to be visited heavily by people and therefore speed is a priority for me.
I will create a frontend - where people are being redirected to a page - which needs to be as fast as possible - and a backend where I can see the statistics - which doesn't need to be as fast but will be robust.
So I was planning to create 2 separate Laravel projects, one for the frontend and one for the backend.
The reason I'm thinking this way is I don't want the backend files, etc to be slowing down the entire frontend by loading in unnecessary files, packages, routes, etc.
Am I thinking correctly and if speed is my priority, should I separate these 2 projects?
The reason I'm thinking this way is I don't want the backend files, etc to be slowing down the entire frontend by loading in unnecessary files, packages, routes, etc.
They don't.
Laravel only loads (via the Composer auto-loader) most classes when they're used. If your code (controller, view, etc.) doesn't call App\Foo anywhere for a particular request, App\Foo isn't loaded.
If this is your reason for all the extra complexity of two different codebases, don't do it.
Related
I've run into a problem that I'm sure many new/junior web developers are facing. Before I state the problem, it's best if I first list the events that drove me to the "issue".
Step 1 - The Front-End:
I followed tutorials which allowed me to create a Vue project using the vue-cli - I now have a nice front-end ready to go, albeit it is in a way "standalone". It sits in its own directory.
Step 2 - The Back-End:
I move on, I start to look at the back-end. Laravel plays well with Vue so I go with it. Once again I follow tutorials, I create a database and an API. Fantastic.
I now have the barebones core elements for a CRUD application. However, the way the back and front end are connected seems to be convoluted (although this may be due to my inexperience and improper understanding).
Solution 1:
Some tutorials insist that the Vue project is "re-created" within the Laravel directories so Laravel is in charge of rendering the views.
Solution 2:
Others, from what I can tell keep them physically separate and have the front-end interact with Laravels API only.
What are the best practices when it comes to stack architecture? Should we aim to bundle the stack together as proposed in solution 1? Is solution 2 even possible or is that due to my misunderstanding? If it is, how is deployment handled?
From my point of experience, both are correct and the answer depends on what you want to build 😀
First, if you have a simple website and you want to make the front-end of it in vue and it is only this one website, you can put it all together and make the frontend in Vue, which is handled by laravel in the backend and you are done.
Second, the step further, is for this case, that you can have several frontends for your project. Example: You have a website and several (native or universal) apps to display your data. In this case, you can build an API, that handles all the logic, all the business secrets, and this stuff, that no one should know in detail. After that, you are free to build any frontend (Vue, native, plain-HTML), whatever) you like, that's the only purpose is to display the data the API gives back (with some little logic in it, of the cause, but the secret business logic is hidden in the API). You can even outsource the generation of an app, so you build the website frontend in Vue and another one can build an ios-app with swift or an android app with kotlin.
Hope, you get the point, the answer is, as often: it depends 😉
I am starting to write my first web app with Node.js and Express. I have two approaches in mind.
Create two sets of routes. One that sends JSON, one that renders the page using a templating engine
Create a static website that makes API calls to the backend using AJAX, and have only routes for the API.
I understand that approach #2 depends on AJAX support in the browser, but if this was your project, based on the advantages and disadvantages of each approach, which would you choose and why?
If I am reading it right, both options #1 and #2 first set of routes is an API that returns JSON rather than sends it.
Assuming that in #2 you wouldn't create static pages with JavaScript doing AJAX calls, but rather still use express static routing like app.use('/', express.static(path.join(__dirname, 'dist'))); the difference between 2 approaches isn't that big.
Unless you already know some supported template language, such as mustache the cons are that you have to learn one and before that pick one (which isn't always an easy task from my experience!).
If you don't know one, depending on your application, you might still benefit from learning and using one. As an example you can think of a very generic UI where a single template could be reused very many times - like a generic database UI similar to, say well known phpmyadmin.
In case of static routing, you can achieve similar results by using a JavaScript framework which has components or templates, such as angular. If you aren't planning to use one, that could result in a lot of code duplication of otherwise re-usable widgets. And even when using one I can imagine a case when template engine would result in less code (or less files in your project at the very least). Not sure though if it's going to be easier to navigate and moreover to cover with tests when the project grows.
Without knowing more about your project it is hard to give more advice.
If the product you're developing is primarily static content with some dynamic pieces here and there, I'd recommend serving HTML from your backend via a templating system. A good example of this would be a blog. You'll end up with better SEO and there are less moving pieces to grok in this approach.
However, if you want to develop a single page application, I recommend using your backend entirely as an api, and writing your client side logic entirely in React/Vue/Angular/whatever. Single page applications have their front ends written entirely in javascript, and are best suited to highly dynamic, "app like" experiences online. Think gmail or facebook.
In my current project we use both approaches. Many views are static and data is obtained from API calls (we just use angular) or bootstrapped values (we load some objects with template, like user roles etc.)
However, some views are rendered on server site, because it easily allow us to dynamically inject values, tokens or other supporting data without making extra requests.
So, I vote for flexibility
How to update data in multiple places without reloading the page in Vue.js?
This is my example.
When I add a new application, a new reminder is created. How to use this data in different places on the page?
Important: all elements are in different components.
Use Vuex or a global event bus depending on the complexity of your application.
If your application is starting to become more enriched with Vue components that need to communicate beyond simple child/parent and parent/child communications, then Vuex should be a good fit.
I am not going to go into depth about the technicalities because that information can be found in the documentation. Good luck.
I don't even know if this is even possible, but I thought I'd ask.
I am creating a small CRUD application but I have multiple sites. Each site would use the CRUD. The application would have common CRUD methods and style, but each individual site would apply different forms. I want to avoid creating multiple CRUD applications that varied only in specific content (just different forms).
I want to have something like this:
mycrud.website1.com
mycrud.website2.com
mycrud.website3.com
I can create a subdomain for each individual site no problem. But is it feasible to point all the subdomains to one MVC application directory? And if it is possible any suggestions for how I might go about restricting users from website1 from seeing website2 or website3 content? Is that something "roles" could take care of (after authenticating user)?
Thanks.
There are a lot of websites that do this, not just with MVC. Some content farms point *.mydomain.com to a single IP and have a wild card mapping in IIS.
From there, your application should look at the URL to determine what it should be doing. Some CMS systems operate in this manner, using the domain as a key to deciding what pages to load.
I've built a private labelable SAS application (Software as a Service) that allows us to host all of our clients in a single application. Some clients have customizations to pages or features. We are able to handle that by creating custom plugins for each client that over-ride the Controllers or Views when needed.
All clients share a common code base and aside from each clients custom theme/template they are the same. Only when a client had us customize one feature did we need to build out their plugin DLL. Now, this is advanced stuff so it would require heavy modifications to your code base but in the end if it's what your application needs it is 100% possible.
First - the easy part is having one web site for all three domains. You can do that simply with DNS entries. No problem. All three domains should point at the same ip.
As far as the content, you could do that in a number of ways. I think your idea of roles is pretty solid. It also leaves open the possible of a given user seeing content from both site1 and site2, if that would ever be necessary.
If you don't want to force users to authenticate, you should look at other options. You could wrap your CRUD logic and data access logic into separate libraries and use them across three different sites in IIS. You could have one site and display content based on the request URL. There's probably a lot of other options too.
I have a website that uses CakePHP 1.3.10. This CakePHP app it's pretty big, not in the amount of models or controllers (like 5 of each), but in the amount of plugins. I use the plugins as places of the website where users can access (or can't access) depending on if they have logged in already or not (well there's more reasons, but it's not important now, it's how it works). I also use a global Auth component in the app_controller.php
My issue is the following: I've noticed that the website is getting really slow when trying to access any of the pages of a plugin (when accessing the "home" page - which is not in a plugin - all is good).
The thing is that I was going to run some performance tests to figure out what's going on. I decided to create another website, exactly like the one I described, with the only difference that I removed all the plugins with the exception of one.
Amazingly (for me), when I access one of the pages of this plugin that I didn't delete, it goes super fast, like it should normally go.
So my question is: does the number of plugins really have a direct impact on the loading times of a page inside those plugins? Is there any way to "fix" this? Or is it just a coincidence and something else is going on that I missed?
Thanks so much in advance for any advise!
Reducing the amount of files and folders of my application has increased significantly the load times. I don't know what is the relation between amount of files/folders and loading speed in CakePHP, but it's a fact, at least in my website.
I've changed my cake installation to an advanced installation (as it explains in the cakephp boo) to have my files more spread out in different sub-apps, instead of having one huge app, and this has helped a lot!