Instructions don't say to include .env file in package includes

[oppiansteve]

Spent ages debugging the errors that happened because the .env file wasn't included (gets an error with the DebugServer, then that errors with the translation class being missing).

Easy fix was to add .env to the list of packages to include.

Might also be worth mentioning that the APP_KEY and APP_URL needs to be configured.

[oppiansteve]

Now worked out why my migrations aren't migrating - the database directory isn't in the list of includes either :-)

(for anyone else following along at home, I also needed to set Schema::defaultStringLength(191) in the AppServiceProvider::boot() method to stop it giving a key too long error - this is with Aurora Serverless)

[mnapoli]

Is this for Symfony? Laravel?

Please send a pull request to improve the documentation :)

[oppiansteve]

Sorry, this is for Laravel - missed out that important point!

I'll try to create a pull request for you.

Thanks

[mnapoli]

OK that's interesting because I setup a Laravel app last week and had no issue. Did you add these hooks as mentionned in the docs:

hooks:
    build:
        # Use the `.env.production` file as `.env`
        - 'rm .env && cp .env.production .env'
        - 'rm bootstrap/cache/*.php'
        - 'php artisan config:cache'

The config:cache will cache env variables from .env into Laravel's config cache. So there is no need to deploy .env after that.

And did you set the environment to production in .env.production?

Might also be worth mentioning that the APP_KEY and APP_URL needs to be configured.

Ah right we had to set those in the config.

Now worked out why my migrations aren't migrating - the database directory isn't in the list of includes either :-)

Right, this should be an easy fix in the docs

(for anyone else following along at home, I also needed to set Schema::defaultStringLength(191) in the AppServiceProvider::boot() method to stop it giving a key too long error - this is with Aurora Serverless)

Ah this is a pain, this is because of UTF-8 support, but it's not specific to RDS/Bref.

[oppiansteve]

(I'm using Laravel v5.7.13, btw)

yep, looking in .bref/output it had the correct .env (i.e. the hooks were working as far as the cp at least), but in the zip, it was missing, of course, and seems I needed the .env even for it to pick up anything.

yep, had it set as production in the .env, but my caching step must not have cached everything or in the right way.

With the .env file included, everything worked fine and after including the migrations, it didn't take long to get it working with Aurora Serverless; love that scaling down to no instances!

I've not put any (significant) custom code into my Laravel yet (still working on getting Nova working with assets under /dev at present), so I'm not sure how we could be seeing different things.

Once I've sorted out my current nova issues, I'll try again and see if I can be more specific as to why the .env file seemed to be needed for me i.e. what was wrong with the cache or why it wasn't being used.

(Although might just give up and use a domain so I can have everything served off the root anyway, which should allow it to work out of the box, I'm guessing).

[mnapoli]

Yes it gets really easier when you have a domain, I really hate that dev prefix ^^ It makes those things harder.

I guess we could also deploy .env by default to be sure, it's not like it's a huge file.

[oppiansteve]

I have two issues with nova at present (with a domain) - feel free to tell me to create a new ticket or to read the docs, if the info is there, but...

I have to include the public folder (and also manually copy in the public/vendor) folder before deployment in order for nova to get to display its view (as it looks for the mix manifest file in the directory to get that far.

I'm wondering why the vendor directory in the public folder isn't copied in when I use the include string 'public/**' and even with 'public/vendor/nova/**'.

Now I do appreciate that this is probably the wrong way to get the nova css to actually serve - as it is served as content-type: application/json (with the path /vendor/nova/app.css?id=fdf84a70c621d6f1fa27).
I should look around more and read the code to find out why and what the right way of doing this is.

[mnapoli]

Oh *** your issue with the public/vendor folder might be related to #51 (which is caused by this Symfony issue: symfony/symfony#28158).

Now yes you probably don't want to serve assets from PHP/your lambda. The best course of action is deploying it on a CDN, the easiest being AWS S3.

Then you have 2 options:

• use a separate domain for S3 (very easy, I highly recommend it)
• use the same domain: you'd have to use CloudFront in front of S3 and API Gateway (it's basically like having an Nginx that dispatches between the PHP app and assets based on the URL)

I did the second option once for my blog (Symfony app, see here the CloudFormation config: https://github.com/mnapoli/mnapoli.github.io/blob/master/serverless.yml#L45) and it really sucks.

I want to make it easier in the future to deploy websites, but for now I haven't had time to write a guide about it neither write tools, I can't commit but hopefully in the next months I should be able to work on those problems.

So to be honest, deploying Nova on AWS lambda is (IMO) quite a feat. You seem to get close to the end though, I'm curious you may actually make it ^^ Deploying APIs or workers (or smaller websites) is definitely easier. Hopefully this won't discourage you with lambda's altogether ;)

[oppiansteve]

I was hoping I could serve from the lambda and cache via CloudFront on the API Gateway - should be very trivial to configure (in principle).

I'm tempted to try intercept the request and fix up the content type (and hack copying of the public vendor directory) - unless you think that's a terrible idea :-)

Nah, I'm having fun - I'm learning a lot about Nova et al. by trying this.
Although the next real problem was getting a 419 response when logging in - not tracked that down yet.

[oppiansteve]

Actually, deploying the assets to s3 as part of the build process could be quite nice - my biggest concern is synchronising the code and asset deployments - I guess the best way would be to version them (by using different paths, rather than file versions, I mean) in s3 and the new code would have baked in a version in the paths requested. Yep, that does sound quite fun :-)

[oppiansteve]

My plan is to use the lambda version for the development, then Fargate for stage/prod and lambdas for the workers.

Trying to make it very trivial to experiment whilst costing very little with little admin.

[mnapoli]

I'm tempted to try intercept the request and fix up the content type (and hack copying of the public vendor directory) - unless you think that's a terrible idea :-)

I want to try that out too out of curiosity. First requests wouldn't be great though so if you deploy often that's not really good.

my biggest concern is synchronising the code and asset deployments - I guess the best way would be to version them (by using different paths, rather than file versions, I mean) in s3 and the new code

Yes that's a good idea

[oppiansteve]

S3 actually isn't very speedy (although would be quicker than code), and actually fails much more often than one would like! On balance though, it is probably a good idea :-)

[mnapoli]

Oh really, I had no idea! Now I got something else to dig into ^^

[oppiansteve]

when doing millions of requests you see a fair number of errors and they tend to group together, presumably when overloaded or doing upgrades.

Having a CDN on top of it (with non-caching of errors) works well.

On the upside, got 'public' assets serving through Bref fine. Nova be pretty now.

Now just the 419 return code to sort out :-)

[oppiansteve]

Cool, nova now working fine, although have temporarily stopped checking the CSRF on the nova login (as the sessions are lost, of course).

So, next step is to add an external session service possibly moving it into the DB (or cookie perhaps) and then cleaning up some of my hacks (force copying of the public/vendor directory etc.).

[oppiansteve]

This was a stupid mistake by me, trying to determine whether running in bref through the environment.
I'll re-do that logic, which should remove the need to add the .env file.