I am creating a web application. I am fairly accustomed to Laravel and how it functions. I would like to know how I incorporate Ember into the Laravel setup. I am guessing public folder, but when I use Yeoman to install Ember into the public it involves the node_modules and gruntfile. My question is should all this be in the public folder (any security concerns?)
Some people say it is not good to mix the two. I would like multiple single page views so it makes sense. Plus it is a good challenge to get stuck into. I have researched any answers and had no luck.
You need to put your script files in your public folder, otherwise the clients browser wouldn't be able to fetch and use them. No security concerns there. That includes grunt, bower or any other files (if it happens that you need them in your production server).
We at work use Laravel and Ember. Ember is our true front end and Laravel is our true back end. It is a very good idea to use them together. It's also a good idea to start with multiple apps so you don't get overwhelmed in no time. In time, you can evolve to one huge app and/or you'll start writing components and mixins you can reuse across your apps.
Just a note: I use a combination of bootstrapped data (json_encoded in .blade views) and data fetched from the server via getJSON (I don't currently use Ember Data because is not production ready yet)
I hope this helps you!
Related
I have been developing a website that uses Laravel (v6) on the backend, and Nuxt.js (v2) on the frontend. The idea was for laravel to act as an api & oauth2 server, that also server side rendered the Nuxt.js app. From my research, it seemed like this was not only a common route, but not too much hassle to implement.
While developing, I have kept the backend and frontend as completely separate projects with their own git repos and all that jazz. This is my first time deploying/developing a project like this, where there are two completely applications for the backend and frontend, so all this is very new and a little challenging at times. Now when it came time to deploy them, I always imagined that I would somehow merge the projects and that I would be able to setup Laravel to server side render the Nuxt.js app. However, I am now at that stage and trying to merge them with great difficulty.
Currently I am using the "laravel-nuxt" composer package and "laravel-nuxt" npm package in an attempt to connect the projects in one repo. However, I am having difficulty doing this. I've searched far and wide for a good resource on this process and have yet to find one that explains the process thoroughly. I even purchased a course on Udemy on the topic only to find out they didn't merge the projects! They deployed Nuxt to firebase and didn't even cover how the deployment of laravel.
Anyway, this is my question(s): should or could I keep the projects separate and have 2 completely separate deployments? Or rather, if I keep them separate, how do I deploy nuxt in a way that still gets server side rendered? To me it doesn't matter if they are separate or together, but the most important part is that the nuxt app utlitlizes SSR (server side rendering) for SEO purposes. So am I on the right track? Should I keep these projects separate or should I continue trying to merge them?
Sorry if this is unclear, I am rather frustrated and kind of losing my mind. I would really appreciate any feedback or point in the right direction. Thank you for your time in reading this, and I otherwise hope you have a good day :)
I recently developed something with a similar structure, Nuxt.js frontend and Directus CMS as backend.
I kept backend and frontend separated repositories and also deployed both separately. The reason why I decided to do it that way was because both need different packages on the server side and use different eco systems.
Frontend needs only Node.js backend needs a webserver, database and PHP. I think this should not be mixed.
For backend I used my existing server where I already have stuff running like Nextcloud or a blog behind a nginx webserver.
For frontend I used Dokku which I can only recommend for deploying Node.js apps. Nuxt.js has instructions on how to deploy to it.
Most important for you is that SSR is done by Nuxt.js, you don't need a separate webserver for that. Just build it and use npm start. Depending on your installation/deployment you have to use nginx as proxy to avoid calling the app with a port number. Another thing that Dokku does for me automatically, if the app respects the PORT environment variable.
I've made an online store in php for school, and now my teacher wants this project to have a Laravel Framework. And I have no freaking idea how to do it. Are there any possibilities to implement this framework to my project, or my project to this framework, without starting from scratch? If yes, how should I do it?
irrespective, its going to involve a lot of rework. A lot also comes to down to HOW you've developed your original php app. Laravel is a Model View Controller framework. For starters all your routes (http redirects) are generally managed in a single file (web.php). Your views can be traditional php, however, Laravel gives you a good templating engine called Blade which allows you to shorthand code and keep code a lot cleaner. Models control your table relationships, controllers handle the functions/code/crud etc.
You will love how easy it is in most respects - especially the way eloquent data queries work etc. It can greatly reduce your code.
If your teacher wants you to LEARN Laravel specifically, I would say YES you will be starting over - however, your logic in the code should just need reworking rather than start from scratch.
There are heaps of posts around HOW to install Laravel (apache, virtual box, homestead etc) - once your ready, its super simple to create a new project and start building away... If you are new to MVC, you should do some tutorials first (e.g. laracasts or other).
Best of luck :)
I am looking to implement Angular2 inside my current Laravel project. I've read about many setups including AngularClass's version with Webpack, but I feel like it's all over-complicated.
What I wish to make:
A simple single page app inside my Laravel app.
It needs to have something like Grunt/Gulp or even Webpack to compile upon changes.
Does not need NodeJs to run in production, no lite-server, just like AngularJS it can be injected and that's it.
I need to understand the implementation files to achieve this, so no starterpack or angular-cli, unless if you can supply good arguments.
Looking for a "how to"-like example on creating the above.
Thanks in advance.
EDIT: More information
As ANKH pointed out, i needed a more detailed and coursed question. So here we go:
- Looking for a example implementation of a Angular2 based SPA inside an existing PHP application (Laravel).
- I've tried many different tutorials, going from the heroes tour, to Sitepoint and AngularCLI based tutorials, but they all assume a SPA on it's own. Ergo, they are compiled and served through NodeJS, which I don't need.
Turns out that I've actually been looking at this entirely wrong. I've gone with using Angular-cli and found that I could generate the output files and include these inside my Laravel project. No need to integrate them further.
I recently started to develop a social network, but the problem is i started to mix my Laravel view with AngularJS what led me to a few problems.
I was searching around the net but was not able to find any info about this.
Could someone help me out with this or give me a hint?
I prefer to decouple my Angular.js application from the backend (any backend). You can pick a tool like Linemanjs or Yeoman.
With Lineman (which is the one I use) you develop your app without any backend, in an "isolated way". You can use a fake backend while you are in development mode or even you can have laravel running at port 4567 (just an example) and tell lineman that there is a real backend at 4567 to create a proxy (so you can use your real backend even when your app is in a different folder).
The advantages are many. Decoupled from any backend, so you can switch it to others without any change in Angular. You can take advantage of a pre-configure set of tasks for grunt like Coffeescript, lint, sourcemaps, auto creation of $templateCache, ngmin to avoid minification problems, minification, concatenation... And more if you want.
You also have unit and e2e tests preconfigured...
In short, using this workflow you can create an Angular.js app which plays with any backend and provides you with a lot of tools to create your app easily.
To deploy, both lineman and yeoman creates a "dist" folder with your app itself, just a bunch of static files.
To deploy it with laravel, you just need to drop everything (except the index.html) to the /public folder of laravel. Then convert the index.html to something like home.php in the laravel's /view folder and create a route for it.
We only need to be able to serve the index.html with laravel and that is the best way I found. With that we are able to use html5 mode and make everything work perfect and both part decoupled.
Cheers.
I'm working on a project using Zend Framework, which I initially chose since I had a bit more experience in it. At this point in time, I'm thinking of moving to Django, though, as our current team will be more productive in it.
I'm trying to figure out the best way to (potentially) go about this, as we evaluate it. A lot of our code is still fairly fluid, and being re-written fairly often. The way I had considered is that as something ends up being re-done, redo it in Django, and change my PHP model to simply be a call to the Django underbelly and translation to PHP. Over time, we should have all of the models, at least, in Django.
Are there better ways? Particularly, is there any way to easily manage having two codebases at once?
There is no generic answer to cross-language migration projects.
If you can wrap your php code and hide it behind web services, you will be on a good path because you will be able to migrate those web services later without changing the API.
Make a list of the main components of your architecture and try to see which ones could be hidden behind such a web service API.
I would recommend that if your web app is db driven, move your business logic to your db and have your data mappers call db stored procedures. I'm developing using ZF myself, which is a very strong tool, but the immense 'abstracticity' it offers can deviate you from your goals... Then you can mess as much as you like with your controllers and views...