Crud: [4.x] Unable to deploy backpack to Laravel Vapor

Created on 2 Oct 2019  Β·  7Comments  Β·  Source: Laravel-Backpack/CRUD

Bug report

I'm not really sure if this is a Larval Vapor, or Laraval Backpack issue... but I figured I would start here.

Problem 1 Build size

For Laravel Vapor, your application must be less than 45MB compressed. the packages provided by backpack take up a considerable amount of that.

Workaround solution:
Delete the packages from the vendor file before uploading.

    build:
      - 'rm -rf vendor/backpack/crud/src/public/packages'

Docs: https://docs.vapor.build/1.0/projects/deployments.html#build-hooks

Problem 2: Exception during initialization

Looks like $_SERVER['REMOTE_ADDR'] isn't set at this point.

Caching Laravel configuration[2019-10-02 13:57:34] staging.ERROR: Undefined index: REMOTE_ADDR {"exception":"[object] (ErrorException(code: 0): Undefined index: REMOTE_ADDR at /var/task/vendor/backpack/crud/src/LicenseCheck.php:22)

17:57:34
[stacktrace]

17:57:34
#0 /var/task/vendor/backpack/crud/src/LicenseCheck.php(22): Illuminate\\Foundation\\Bootstrap\\HandleExceptions->handleError(8, 'Undefined index...', '/var/task/vendo...', 22, Array)

17:57:34
#1 /var/task/vendor/backpack/crud/src/BackpackServiceProvider.php(45): Backpack\\CRUD\\BackpackServiceProvider->checkLicenseCodeExists()

17:57:34
#2 [internal function]: Backpack\\CRUD\\BackpackServiceProvider->boot(Object(Illuminate\\Routing\\Router))

17:57:34
#3 /var/task/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(32): call_user_func_array(Array, Array)

17:57:34
#4 /var/task/vendor/laravel/framework/src/Illuminate/Support/helpers.php(522): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()

17:57:34
#5 /var/task/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(90): value(Object(Closure))

17:57:34
#6 /var/task/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(34): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))

17:57:34
#7 /var/task/vendor/laravel/framework/src/Illuminate/Container/Container.php(591): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)

17:57:34
#8 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(828): Illuminate\\Container\\Container->call(Array)

17:57:34
#9 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(811): Illuminate\\Foundation\\Application->bootProvider(Object(Backpack\\CRUD\\BackpackServiceProvider))

17:57:34
#10 [internal function]: Illuminate\\Foundation\\Application->Illuminate\\Foundation\\{closure}(Object(Backpack\\CRUD\\BackpackServiceProvider), 15)

17:57:34
#11 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(812): array_walk(Array, Object(Closure))

17:57:34
#12 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/BootProviders.php(17): Illuminate\\Foundation\\Application->boot()

17:57:34
#13 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(211): Illuminate\\Foundation\\Bootstrap\\BootProviders->bootstrap(Object(Illuminate\\Foundation\\Application))

17:57:34
#14 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(320): Illuminate\\Foundation\\Application->bootstrapWith(Array)

17:57:34
#15 /var/task/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(271): Illuminate\\Foundation\\Console\\Kernel->bootstrap()

17:57:34
#16 /var/task/fpmRuntime.php(65): Illuminate\\Foundation\\Console\\Kernel->call('config:cache')

17:57:34
#17 /var/task/vendor/laravel/framework/src/Illuminate/Support/helpers.php(548): {closure}(Object(Illuminate\\Foundation\\Application))

17:57:34
#18 /var/task/fpmRuntime.php(66): with(Object(Illuminate\\Foundation\\Application), Object(Closure))

17:57:34
#19 /var/task/runtime.php(28): require('/var/task/fpmRu...')

17:57:34
#20 /opt/bootstrap.php(6): require('/var/task/runti...')

17:57:34
#21 {main}

Problem 3: Too many public assets

Due to the number of public package files published in the Laravel Backpack admin theme, (4191) (find packages -print | wc -l), Laravel Backpack cannot be deployed to https://vapor.laravel.com.

Laravel Vapor has a requirement of a max of 300 public assets.

Project built successfully. (0m24s)

==> Uploading Deployment Artifact (28.12MB)
 28792KB/28792KB [============================] 100% (< 1 sec remaining)


Whoops! There were some problems with your request.

    - Vapor applications may not have more than 300 public assets.

What I did

  • Attempt to deploy Backpack to our Laravel Vapor deployment.
  • Attempted to delete any of the packages I thought weren't necessary for our deployment... I was only able to get down to around 600 files.

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

### PHP VERSION:
PHP 7.3.10 (cli) (built: Sep 30 2019 19:59:06) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.10, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.10, Copyright (c) 1999-2018, by Zend Technologies

### LARAVEL VERSION:
laravel/framework                      v6.0.4     The Laravel Framework.

### BACKPACK VERSION:
backpack/crud                          4.0.5      Quickly build an admin in...
backpack/generators                    2.0.4      Generate files for larave...
vapor --version
Laravel Vapor 1.3.0
Feature Request MUST

Most helpful comment

So this only works if you use only the most basic of packages provided by Laravel backpack. If you're using something like CKE-editor I am not confident you'll be able to get below 300 assets.

What I did was write a janky script that removes all sorts of files during the Laravel Vapor build step.

You can find a rough idea of what I did here:

https://gist.github.com/mwisner/35b0088f9d4ae24911fc69452338d98a

using this I was able to go from 4k+ assets down to around 150.

Using this script + my fork that fixes the missing IP issue I am able to get Backpack running great using Larvel Vapor.

All 7 comments

Hello there! Thanks for opening your first issue on this repo!

Just a heads-up: Here at Backpack we use Github Issues only for tracking bugs. Talk about new features is also acceptable. This helps _a lot_ in keeping our focus on improving Backpack. If you issue is not a bug/feature, please help us out by closing the issue yourself and posting in the appropriate medium (see below). If you're not sure where it fits, it's ok, a community member will probably reply to help you with that.

Backpack communication mediums:

  • Bug Reports, Feature Requests - Github Issues (here);
  • Quick help (_How do I do X_) - Gitter Chatroom;
  • Long questions (_I have done X and Y and it won't do Z wtf_) - Stackoverflow, using the backpack-for-laravel tag;

Please keep in mind Backpack offers no official / paid support. Whatever help you receive here, on Gitter, Slack or Stackoverflow is thanks to our awesome _awesome_ community members, who give up some of their time to help their peers. If you want to join our community, just start pitching in. We take pride in being a welcoming bunch.

Thank you!

--
Justin Case
The Backpack Robot

i didn't use vapor yet but with a little search i found that blog.laravel.com

Hi @iMokhles, thanks for pointing that blog post out.

I added another issue that I forgot about solving the issue description. Basically, to work around this all I did was remove the packages from build during deployment.

https://docs.vapor.build/1.0/projects/deployments.html#build-hooks

PR Added to solve problem 2. (https://github.com/Laravel-Backpack/CRUD/pull/2119)

Now working on some sort of asset solution

So this only works if you use only the most basic of packages provided by Laravel backpack. If you're using something like CKE-editor I am not confident you'll be able to get below 300 assets.

What I did was write a janky script that removes all sorts of files during the Laravel Vapor build step.

You can find a rough idea of what I did here:

https://gist.github.com/mwisner/35b0088f9d4ae24911fc69452338d98a

using this I was able to go from 4k+ assets down to around 150.

Using this script + my fork that fixes the missing IP issue I am able to get Backpack running great using Larvel Vapor.

Hi @mwisner ,

Thanks a lot for posting about your problems and progress with Vapor here. I'm 100% sure people will find this useful. And I do think it's important to be able support Vapor - so we _definitely_ should make it seamless to deploy projects that use Backpack on Vapor. Let's see how we can best do that.

Problem 1. I think this will be solved by installing vendors separately in Vapor. Please correct me if I'm wrong.

Problem 2. I've just merged your PR for it. Thank you!

Problem 3. This one is painful πŸ˜„

You see, in v3 we were using CDNs to load CSS&JS assets, which would solve the public folder size problem. Most jQuery plugin assets weren't in the folder at all. However, in v4 we pulled in everything using npm, and published the assets in the public folder, so Backpack can be used on intranets with no internet connection. Plus, it's a security/privacy improvement - nothing's as safe&private as hosting the assets yourself. Now, the trick is to find a solution that solves both problems (use on intranets AND deploy on Vapor).

(Solution A) For now, I see only one possible long-term solution. We could create a big-ass-bundle that includes all assets needed for fields - fields.bundle.js and fields.bundle.css. But:

  • the bundle files would be HUGE; it would make the first page load very VERY slow, and basically cancel out a BIG benefit of running a server-side rendering (loading assets as they're needed, instead of loading a bunch of JS that few pages use);
  • it would be uncomfortable to add new items to the bundle, if you create a new field type (you'd have to edit a file, and run laravel mix); so the workflow would be as unconfortable as running a SPA;

Because this solution cancels out something I love about Backpack - the ease of customization, I don't really like it. We _could_ do it as opt-in, to only make it more difficult for people who use Vapor (a minority), but... it wouldn't be a great experience for them either.

I'll think about this some more, try a few things, and get back to you. If anybody has a better idea, please let us know.

(Solution B) Just thought of this - if we can have all public assets in the vendor folder (Problem 1 solved by having the vendors separately instead of having to delete somthing from it), maybe we can just:

  • not have the public/packages folder in the repo (gitignore it);
  • publish the CSS and JS assets from vendor upon deployment; this should be as simple as having this in our deployment process
php artisan vendor:publish --provider="Backpack\CRUD\BackpackServiceProvider" --tag="minimum"
php artisan vendor:publish --provider="Prologue\Alerts\AlertsServiceProvider"
# maybe, if it's used
php artisan elfinder:publish

(of course, we can make a command that does all that, something like php artisan backpack:publish-packages)

What do you think of Solution B @mwisner ?

Just thought of a way to reduce the /vendor/ directory size in production:

We don’t really need all CSS and JS in the vendor folder in production, do we? They’re not really used from vendor there. We could split that into a different package, that’s only required-dev in composer. That would install it on localhost, where you publish the assets, but not in production, where you don’t.

Food for thought.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AlexanderWM picture AlexanderWM  Β·  3Comments

packytagliaferro picture packytagliaferro  Β·  3Comments

voidstate picture voidstate  Β·  3Comments

sonoftheweb picture sonoftheweb  Β·  3Comments

sseggio picture sseggio  Β·  3Comments