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.
Related
I have to begin a new project and that's 2 years ago that I'm working on SAPUI5, But for severals reasons I have to use the Laravel 5.1 Framework to handle the database logic and controller to get and put data from and to the database.
I appreciate the power of SAPUI5 and I would like to use it for the front-end of my app.
My question is : It is possible to handle a server application with those two technologies?
My second question is : Which hosting I have to choose, because that my client want a kind of desktop app, and for this I thought to use node webkit package. And for that i have to launch a node server. In my goDaddy shared hosting i don't have this possibility.
Thank you for your help!
You can definitely combine Laravel as back-end technology with SAPUI5/OpenUI5 as front-end technology. As Laravel provides the front-end with restful services, you're probably best-off leveraging the JSONModel in your UI5 application.
Laravel is a PHP framework, so you'll need to look for a PHP host. If a host is capable of running PHP, it is also able to serve the static UI5 content.
If you want to package your app as a desktop application, NW.js will work, but Electron will do the job too. A very nice comparison between the two frameworks can be found here: http://tangiblejs.com/posts/nw-js-electron-compared.
Please do note that both frameworks turn your application into a desktop application and will run on the desktop. You won't need to find a server that runs node.js. You do need a server that runs PHP for your back-end Laravel logic.
After some fiddling building a package for a project we've realised there's some issues with doing what we need to achieve as per Laravel 5 package development clarity
Maybe I should rather explain my goal and someone can suggest a direction to head in.
We've built a Laravel 5 application that now needs to be "re-used".
We had to modify Laravel and implement an Eloquent type base model as our data-source is actually C# Web Services. At the point the call would be made to a database we intercept this and make an "API" call to SOAP.
The major difference will be CSS, maybe some JS & content but all the routes/controllers/models will remain the same across all projects. Most configuration comes from endpoints.
Initially we considered creating multiple asset repositories for each site's styling and have a base repo which is the core Laravel project that gets included. This seemed to get quite complex as we couldn't simply just have a repo in a repo due to branching and multiple directory issues.
We then started experimenting with the idea of building the "core" as a Laravel package but we seem to constantly hit walls. The latest problem being including models in the package. For the models to be called we are using the root projects config/composer to access these models instead of just the service provider. It feels like the package is becoming to tightly coupled to the project config.
Are there any better ways of going about what we are trying to achieve?
Edit:
I forgot about the multiple branch solution on 1 repo but wouldn't this get ugly when it comes to feature development? Example:
master (core with releases that get pulled into _site*)
dev (master dev)
feedback-form (eg. master branch feature)
_site1 (root site with releases)
_site1-dev (_site1 dev)
_site1-reskin (eg. _site1 feature)
_site2 (root site with releases)
_site3 (root site with releases)
This leaving quite a bit of destructive merge power in the developers hands? Read access with pull requests maybe a solution to this?
So after some R&D it seems the best solution right now is to have 1 repo with multiple branches. Developers have read access and have each developer creates his own fork. Developers create pull requests and sync to parent repo through "upstream" remote and developers sync each others forks through additional remotes.
Seems a little clumsy but probably "cleanest" option.
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 need to know which are my options when deploying codeigniter/laravel apps.
I develop locally all the time at my home and when i go to work i need some quick way to push all the changes to the server.
Application code needs to be updated, database schemas need to be migrated, and application servers must be restarted.
I do all of this manually wasting a lot of time and i need some automated way kinda like capistrano in Rails environment.
What are my options here ??
Update:
I got my own server machine, and everything needs to work on an intranet environment without internet connection.
I've used the following:
Salt - http://www.saltstack.org/
Worked well, a bit fiddly to setup. Super fast deployment. Lots of control. Less learning overhead that Puppet & Chef, has some level of native MySQL tools.
GitHub
Requires a internet connection to/from your machine - one where, at some level, the end point as write permissions to interactive scripts.... Works, but makes me nervous. Pulls are better than pushes, and it's better than most other solutions.
Custom shell scripting
Yeah - this is the most common, just tar up the entire CI dir once it's been validated on staging and push out using Salt...
Scalextreme
We've been looking at this for a few months - the interface is from the 1990's, but it's got really nice functionality, including system-independent script library that you can target at any machine.
Turnkey Linux
The hammer - this will migrate an entire system image from a desktop to EC2 is something like 5 minutes. Works great and you can also move stuff between VM systems. In the end, I think that updating AMI's on EC2 is so easy that this might be one of the answers...
Nothing has truly been satisfactory and DB schema changes are a huge pain. So much so that for client configs, we're moving from MySQL to Cassandra, which is basically schemaless. CI installer is interesting, but I'm not sure how it handles updates.
I recently came across this CodeIgniter Installer on GitHub. I've played around with it a few times and it works like a charm for me.
It's as simple as putting it in your root directory (alongside your system folder), generating a MySQL dump, and editing a few files. Full instructions are here
I hope it works for you as well as it did for me.
I found this Laravel Installer on Github which might be useful. (First I came across this question after searching for Laravel installer in Google, then searched Github for Laravel Installer)
I am developing an application with Ruby on Rails (will be more to come) and it has got to the stage where I would like to remotely host a development version, followed by a production one. I have done lots of rails development but I am reviewing my current setup and would like to make sure I do things the industry recommended way form now on.
I already have a dedicated server which is running parallels plesk and has several domains on it. I have currently had some success by creating a new user "passenger" to run the rails app and deploying via that user to an apps directory under
/var/www/vhosts/myrailsapp.com/subdomains/dev/
which is the parallels-format for site directories, deploying using capistrano and running the passenger module for apache. I have basically been putting my rails files where I would put them if it were a plain php site or similar and I was wondering if this was the way things are usually done?
I also found some information online which points at putting my rails apps under
/var/apps/
or similar, but then it would conflict with the parallels plesk way of doing things which could potentially cause issues, or could it?
I have already looked at solutions like Heroku and they won't quite work as I need to run other programs alongside my rails app on the same server to handle some real time server to server file syncing of files uploaded using the app. Added to this I need to ideally be able to host normal PHP applications alongside my RoR ones to make best use of the server.
How should I ideally go about implementing this sort of setup for secure hosting and deployment? If needs be (i.e my current setup is far less than ideal) you could assume I am starting from a vanilla ubuntu server install which I would be open to if it produced a nicer system to manage.
I figured many people would have had similar situations and so any advice from any of you veteran Rails/PHP developers or server admins would be greatly appreciated.
Many Thanks,
Peter
Normally it's a bad idea to put your Rails project files anywhere in your public html space because you don' want anybody to be able to put something like http://yoursite.com/config/database.yml and access sensitive information. Even if that's not possible under normal situations, it could still happen if you have problems with Passenger starting up correctly or something similar.
So I would recommend putting your Rails apps in /var/apps or /srv/apps (as we've done) and setup the Apache config to point your domain or subdomain to that directory.
If you want to have your app accessible by a subdirectory on an existing domain it takes some additional setup but that can also be done.