Critical Caching issue in Laravel Application (AWS Server) - laravel-5

I am facing a critical issue in my application, it is developed in Laravel and Angular. The issue is I am getting the old email templates on live site and on local server I am getting the latest updated one. The process to deloy the code is automatic, I just to commit the code in BitBucket and after that Bitbucket Pipleline push the code to AWS server directly.
I have already run the cache cammands for Laravel and restarted the jobs but still i am getting the same issue. If anyone have expirienced the same issue or have knowledge of the same to resolve, Please guide!

I think you can try one of the following ways to overcome the issue, I faced a similar issue and resolved it by following ways -
Try deleting the cache files manually from Laravel from storage/framework/views
Upload the code directly into AWS for particular module without using the pipeline way
restart your server
This will surely resolve your issue!

Since you are using Laravel and angular application deployed on AWS,
I assume that bit bucket is pushing code and build commands are fired on every push
there are few things which can help you.
Try to build the angular side on every push, since angular builds hashes all the files in the dist folder
Try to delete the Laravel cached files which are stored in storage/framework/views
Check that on that your server is pointing to the right project folder
If any of the points from 1 or 2 works you can automate the process by passing CLI command after every push,
Point 1 and 2 are achievable by passing CLI commands.

Related

Production Server and Local Server get different result

I build API project using Laravel 8, and I put my project on Git. My production server using Ubuntu Apache. I use only 1 database, and it's use on my local and production server.
I have weird problem since yesterday and make me confused. So, I push the latest commit to my Server from Local Server. Everything went well. But when I try to run my API via Postman, the results from my Local and Production server are different.
I checked manually in the files I pushed from local, everything is exactly same.
I try git status, everything OK. git pull are up to date. Here i attach the screenshoot.
Since i use laravel, i try to clear cache with php artisan cache:clear and it doesn't work.
Here i attach my Postman result:
As you can see, the result are different. I believe, there is no error with my code, It's work well on my Local server.
I try to contact my server provider, but didn't get any solution.
Anyway, this is Header from Prod Server
I'll appreciate all the answer from this thread. Thank you
Are you working on same branch in local and server? check your git branches in both.
Thank you for the answer and comment.
I already solve this problem. The problem pure from my production file and server.
first i try to restart my docker, and then run php artisan config:clear.

Template doesnot exist when running on heroku but exists when running locally

I just created my first heroku app and pushed my code through it onto heroku. While testing it however, it showed that one of the templates didnot exist when it infact does when I test it from my laptop directly on the local server. Please do guide if you have any ideas!(ps.: I am using Windows hence please do keep take that into consideration when helping out!)

Best practise/way to deploy Laravel + Vue SPA application to AWS

I have 2 repositories residing in Bitbucket - Backend (Laravel app as the API and entry point) and Frontend (Main application front-end - VueJs app). My goal is to set up continuous deployment so whenever something is pushed in either of the repos in master (or other branch selected by me) branch it triggers something so that the whole app builds and reaches the AWS EC2 server.
I have considered/tried the following:
AWS CodePipeline and/or CodeDeploy. This looked like a great option
since the servers are in AWS as well. However, there is no support
for Bitbucket out of the box, so it would have to go to Bitbucket
Pipeline -> AWS Lambda -> AWS S3 -> AWS CodePipeline/CodeDeploy ->
AWS EC2. This seems like a very lengthy journey and I am not sure if
that's a good practice whatsoever.
Using Laravel Forge to deploy the Laravel app, and add additional steps to build the VueJS app. This seemed like a very basic solution,
however, the build process seems to fail there as it just takes long
time and crashes with no errors (whereas I can run exact same process
on my local machine or a different server hosted elsewhere). I am not
sure if this is issue with the way server is provisioned, the way
Forge runs deployment script or the server is too weak to handle it.
The main question of mine would be what are the best pracises for deploying the app of such components? I have read many tutorials/articles about deploying a NodeJS app, or a Laravel app, but haven't gotten good information about a scenario like this.
Would it be better to build the front-end app locally and version control the built JS file? Or should I create a Pipeline in Bitbucket that would build the app and then deploy it? Or is it the best to just version control and deploy the source files and leave the whole build process as the last step in the deployment process that will be done by the server that is hosting the app itself? There are also some articles suggesting hosting the whole front-end app in S3 bucket - would that be bad practise as well?
Appreciate any help and resources that would help!
From the sounds of things it sounds like you have two types of deployments you might want to run.
Laravel API: If you're using Laravel Forge already then this is a great way to go about deploying your Laravel App, takes care of most of the process and easy server management.
Vue.js App: Few things you can do here, I personally prefer using a provider like Vercel or Netlify who let you deploy your static sites/frontends for free-low costs. You can write custom build steps but they have great presets that should work out the box.
If you really want to keep everything on AWS then look into how to host static sites on AWS

How to setup Bitbucket Pipelines for Laravel test and SSH Agent to deploy on a remote server

I am developing a project in laravel 5.4. I have repository on Bitbucket. Now I want to setup Bitbucket Pipelines so I can test when anybody commit. I think I need a suitable Docker Image for laravel, I tried some images but they generate errors. Also I want to setup SSH key agent so Whenever I commit in production branch it deploys on server.
I searched a lot on internet to do these things but I could not find anything, If you share any detailed tutorial or something like this it will be helpful.
Thanks in advance.

How to move cloud code from parse.com to heroku

I have moved parse sever from parse.com to heroku. Everything is working fine except cloud code('cloud/main.js' file).
I have replaced "main.js" of parse.com with "main.js" of parse server code and deployed on heroku, but it is not working. Getting following error when I make request from my mobile app
{"code":1,"message":"Internal server error."} (Code: 1, Version: x.xx.x)
Any idea?
Note:
I've followed following link for migrating parse server
https://learnappmaking.com/how-to-migrate-parse-app-parse-server-heroku-mongolab/
Migrating cloud code can range in difficulty depending on how involved that code is. Here's a workflow for validating your code:
1) Check that you can build your Heroku app locally with the right Node version.
2) Comment out all of your cloud code. You want to start introducing your code in parts and make sure it compiles with each re-introduced function.
3) Install the node modules for each service that you use. If you use stripe/mailgun or any other package, add them in your package.json file and run npm install. Then include them in your main.js file with the require('packageName').
4) The cloud server uses Express.js version 4.2 and a Parse.com runs Express version 2.0 or 3.0 but not 4.0. If you use any middlewear then you need to change it to the proper Express 4.0 syntax/methodology.
5) There is no support for cloud jobs so rename all your *.job functions to *.define and comment properly so you can come back to them later. If you did not use cloud jobs then don't worry.
6) If you did use cloud jobs, now you need to setup a heroku worker/scheduler to run those old *.job (now *.define) calls at the proper time intervals you had.

Resources