Help - How to deploy to production

[itjunkii83]

After running yarn run build I have packages/venia-concept/dist however trying to execute this from a virtual host on my local machine produces constant 404 errors as it is trying to POST to www.myvirtualhost.com/graphql which does not exist.

If I use yarn run watch:all I am able to run the site on my virtual host and interact with my online Magento 2 site.

Can you please let me know what I am missing? Upward server? How do I get from yarn run watch:all to something I can actually deploy somewhere?

Thanks for the help, obviously I am new to this stuff - but would appreciate any guidance, I have read through the documentation quite extensively and still can't put it all together.

[miguelbalparda]

I'm having the same issue using develop or master branch + trying to build this with both --env.mode development and --env.mode production. It always tries to fetch current.domain/graphql when it should make the requests to the .env MAGENTO_BACKEND_URL variable. This is how it looks in a live url: https://4f69552836.nxcli.net/ and this is how the .env file looks like

michael@michael-HP-Laptop-15-bs0xx:~/pwa-studio/packages/venia-concept$ cat .env 
######## PWA Studio Environment Variables ######################################
#
#   This file contains environment variables for a Magento PWA Studio project. 
#   PWA Studio uses environment variables for all variable cross-project 
#   values, so that a developer or a build system can override any variable 
#   with standard tools.
#
#   This file belongs at the root of the PWA, and must be named `.env`. 
#   Uncomment and modify variable declarations in this file and they will take 
#   effect throughout the Buildpack tool chain.
#
#   Generated by @magento/pwa-buildpack v5.1.1 on 2020-05-10T18:19:13.763Z.
#
################################################################################

#### Connecting to a Magento store #############################################
#
#   Connect to an instance of Magento 2.3 by specifying its public domain name.
MAGENTO_BACKEND_URL=https://master-7rqtwti-mfwmkrjfqvbjk.us-4.magentosite.cloud/
#
################################################################################

[miguelbalparda]

Maybe we are getting this wrong and current.domain/graphql should resolve somewhere else? I always thought that request was going to the Magento 2 instance to fetch stuff and that is why I expected that domain to show.

[fooman]

There is https://magento.github.io/pwa-studio/frequently-asked-questions/#how-do-i-deploy-to-production. PWA Studio would not be able to talk to an M2 backend directly. PWA Studio talks to an upward server. When developing locally an upward server is started as part of the watch command. There are 2 options of running upward in production, either the js implementation which requires nodejs or the php implementation which can be installed into a traditional m2 store as a module.

[miguelbalparda]

Thanks Kristof! So instead of connecting directly to Magento, we conecto to the UPWARD server trough domain/graphql? In any case I’d expect the domain used is not current.domain/graphql but the domain we configured as the backend url in the .env file, which happens to be a magento 2 installation with the UPWARD module. I now understand the way venia connects to Magento but the issue is still there for all practical matters.

[fooman]

If I understand the question correct you would communicate with upward at domain. And this https://github.com/magento/pwa-studio/blob/develop/packages/venia-ui/upward.yml#L8 would then proxy any request from upward-domain/graphql to backend-instance/graphql.

[miguelbalparda]

So upward domain/graphql is basically a magento 2 instance with the upward module and backend instance/graphql is also a magento 2 instance but this time is for real graphql? Are those the same instances? I thought I was going to be able to deploy the dist folder and use a remote url for the upward domain/graphql and I expected the backend url in the .env file to be that bridge. In my case I deployed the dist folder content to a publicly accessible url and tried to connect it to the test instance which lives in another server. How would my deployed dist folder know how to map current.domain/graphql to upward server to the backend instance? That seems to be failing with 404 as you can see in the url I posted.

[fooman]

So upward domain/graphql is basically a magento 2 instance with the upward module and backend instance/graphql is also a magento 2 instance but this time is for real graphql? Are those the same instances?

They can be as Magento Cloud would do something like it.

The best example I can come up with is https://4f69552836.nxcli.net/create-account vs https://master-7rqtwti-mfwmkrjfqvbjk.us-4.magentosite.cloud/create-account you need something on your domain that lets the browser know the right html and js to load, and that is before communicating to any backend (this particular url is a static route which would not need to query graphql to understand what component to render).

So I guess in short, even if you want to use a different back-end url, you need to provide an upward server via https://4f69552836.nxcli.net/.

[miguelbalparda]

Very well then. For me that means venía is not a standalone js app but something you need to put on top of Magento bc it requires UPWARD. In the case you want to use a remote backend you will probably end up with two instances of Magento running or use something like https://gist.github.com/jissereitsma/c67b8b035ddbc15cde07791dee8a2c8e for a single server setup if I understand this correctly.

[fooman]

You wouldn't necessarily need two Magento instances as you could run UPWARD standalone via nodejs.

Agreed that further information for serving a PWA frontend and Magento instance from the same server is needed.

[miguelbalparda]

The nodejs upward server is a no go for me, there’s no way I can start and keep that process running effectively or even expose it to the internet, at least not in the first phase. I was also trying to avoid editing the vhost to make the install as self service as possible but I’m not sure that’s actually doable at this point.

[miguelbalparda]

One more question: does the UPWARD php specification act as a real server as in you have to start and stop it and expose it to the internet or is it a Magento 2 module that uses Magento’s capabilities? UPWARD JS seems to be a “real” server, how about the PHP version?

[dani97]

@miguelbalparda Im not sure different or same server but can be run on same instance with a connector module, @tjwiebell can help you. The upward-php tutorials and readme gives details only for magento-cloud, https://github.com/magento-research/magento2-upward-connector. this module helps to run upward-php on magento cloud as same instance. Adding this for more reference https://magento.github.io/pwa-studio/tutorials/cloud-deploy/ Hope this helps you.

[itjunkii83]

Thanks for bringing some new life to this issue @miguelbalparda - I have tried to follow the tutorials for getting the php upward server to work with no luck since it is completely geared towards cloud not self hosted...

[tjwiebell]

If you'd like to use the UPWARD connector on a non-cloud deployment, the deltas are:

1. Build your PWA somewhere on the filesystem your web server has access (for simplicity, let's assume this is ./pwa in your document root).
2. Install connector module and configure path to UPWARD file (example with CLI: bin/magento config:set web/upward/path ./pwa/dist/upward.yml)
3. Set all required environment variables, I suggest as close to the web server as possible (fastcgi_param MAGENTO_BACKEND_URL <magento-backend-url>). For development purposes though, you could even set these in the index.php files (I haven't done this in awhile, but it will be either $_ENV, $_SERVER, or putenv(...) to do that).
4. Clear Magento cache, and your / path should now be served through UPWARD with your built PWA. All other front names should continue working, so /admin should still be accessible for backend tasks.

This connector was really only intended for production deploys, as you're not going to get any of the fun node features of hot reload or anything like that. Let me know if I can help with anything else.

[miguelbalparda]

Thank you so much @tjwiebell! Is #3 documented anywhere? Or is it just for the MAGENTO_BACKEND_URL var?

[miguelbalparda]

I was able to find the variables here https://magento.github.io/pwa-studio/tutorials/cloud-deploy/#add-required-environment-variables I'm almost there --> https://b371620e44.nxcli.net/ but now I have weird issues like

TypeError: navigator.serviceWorker is undefined
SecurityError: The operation is insecure.

when it's clear I'm running all this using SSL. Domain is https://b371620e44.nxcli.net/ just in case anybody wants to give it a look.

[tjwiebell]

@miguelbalparda - I'm using Chrome v81 and I do not see any issues on that instance. The error does look like something an unsupported browser might say, but Service Workers are pretty widely supported now. Let us know what browser you're using, and we'll see if this is a compatibility problem we need to create a bug for.

I did want to point out, when using the UPWARD-PHP deployment, you do lose image optimization that we did with an onboard node library, meaning your instance now relies on the backend to handle optimization (which means no optimization unless you have the Fastly module installed). If you're just messing around developing, this isn't a huge problem, but is a problem you would want to solve before go live.

[miguelbalparda]

Indeed @tjwiebell, it looks like the errors I posted are no longer there. Regarding to the image optimization stuff, it's the next thing I'm tackling. This seems to be yet another assumption pwa-studio is making irt the environment where it's hosted since fastly seems to be the only option considered to optimize the images. Again, million thanks for all the help here!!!

[jissereitsma]

I can see this discussion has already gone pretty far. But when I hear that UPWARD is a solid requirement for running Magento PWA Studio in production, I strongly disagree. Maybe it is a suggestion. But the very definition of GraphQL requests routing through UPWARD is that UPWARD is designed to be a stateless proxy, so no caching, no tuning, no nothing. In short, in production, UPWARD would be a middleware layer that is delaying GraphQL calls for no reason. If you are fine with not sticking to the recommendations of Magento (as of yet), I would suggest the following:

Open up the src/index.js file of your PWA instance - you know, the one you copied from Venia - and change line https://github.com/magento/pwa-studio/blob/develop/packages/venia-concept/src/index.js#L17 into your Magento instance.

Before:

const apiBase = new URL('/graphql', location.origin).toString();

After:

const apiBase = 'https://example.com/graphql';

(Actually, you can even use the environment variables for this.)

The end-result is that you do not need UPWARD in production, requests are being served faster and there are no CPU cycles spent on forwarding tasks that are not needed.

Still, I would recommend people to consider a Node server anyway. The hack I mentioned still stands. But using UPWARD, you can then also implement Server Side Rendering. Or use some other SSR solution. But in short, most SSR solutions require a Node middleware server. But that would be my reason to add UPWARD. I would not add UPWARD for forwarding requests that can also be served directly.

[miguelbalparda]

I compiled everything I've learned from this issue here. I think it's safe to close this issue for now given that we managed to deploy this somewhere else than Magento Cloud. Thanks!!

[phtmgt]

I'd like to add some details, as I couldn't find any clear instructions on how to deploy to production in our use case. So I thought this might be helpful.

The upward-connector way does not work for us (first, not compatible with 2.4.2, second, can't get it to work on 2.4.1, because of complaints about missing MAGENTO_BACKEND_URL variable).

upward-js works great running locally at port 8000 behind an nginx reverse proxy. Then we use certbot to get the cert.

For the admin part you can either choose a separate domain (e.g., backend.yoursite.com) or set-up separate locations on the main domain via nginx configuration. The relevant location block is:

location ~ (/admin|/static|/media) {
 # Here we reverse proxy to our m2 docker instance
}

I hope this helps someone and saves them a few hours.

[maheshm-kensium]

I compiled everything I've learned from this issue here. I think it's safe to close this issue for now given that we managed to deploy this somewhere else than Magento Cloud. Thanks!!

@miguelbalparda For 246 version Is there any way I can setup this my local system using linux and apache2? and how to handle proxies and ssl handshakes using openssl?