Can the following setup be achieved with a single App Specification file (= single App)?

  • single managed PostgreSQL Cluster (PCLUSTER)

  • example.com is the main domain and it serves a next.js application from production it branch; it connects to api.example.com

  • api.example.com is Laravel API from production git branch; it connects to production database in PCLUSTER

  • example-staging.com is staging area; it runs next.js from staging git branch and connects to api.example-staging.com

  • api.example-staging.com is Laravel API from staging git branch; it connects to staging database in PCLUSTER

I am confused about how to configure the domains top level setting and routes per-instance settings to make this setup work. Please advise.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
1 answer

@ReWild 👋

Currently all routable components in an app would need to share the same set of domains, so if you wanted your next.js app on a different domain than your API then they would have to be separate apps for now. Similarly for your staging app. This may change in the future, especially if we hear enough feedback about it.

An alternative would be to put your nextjs site on example.com and your API service on example.com/api (via the route path config), within the same app. You then also have access to bindable env variables that can be used to reference other components in your app, on the internal network or external depending on if you nextjs is deployed as a static site or service. In this model, your staging app would still be a separate app for now.

  • Thanks, this clarifies things. If we cannot route subdomains to services individually, what would domains/[Nth]/wildcard=true be used for then? Could you please give an example.

    • Great question. A use-case for wildcard domains would be if you wanted to serve the same app on all *.example.com domains, and possibly render different content or themes depending on the incoming sub-domain (i.e. white-label).

      • In this case, can I have nginx be the “entry point” for the domain and subdomains, and let it route accordingly to various services depending on the domain name?

        For example:

        server {
          server_name api.example.com;
        
          location ~ \.php {
            # ...    
            fastcgi_pass http://laravel_api:9000;
          }
        }
        
        server {
          server_name admin.example.com;
        
          # ...
          location ~ {
            proxy_pass http://nextjs_admin:3000;
          }
        }
        
        server {
          server_name example.com;
        
          # ...
          location ~ {
            proxy_pass http://nextjs_public:3000;
          }
        }
        
        

        Is this a viable setup with the App Platform?

        • Yep that’s a perfectly viable and appropriate setup for the App Platform. Note that you’ll want to reference components on the internal network using port 80 though, so in your example you’d use http://laravel_api instead of http://laravel_api:9000.

          • If http://laravel_api is available at port 80, does it mean that it is also available publicly through some public URL?

          • Currently any service component defined in your app will be available via the app domains on the route path configured for that service. We plan to introduce “internal services” in the future for the use-case where you don’t want to expose these publicly, and just want them available to your other services over the app internal network.

          • @snormoredo any indicative ETA for the internal services feature? This is a deal breaker for our setup. Many thanks!

          • @ReWild I can’t give a specific date, but internal services should be available in the near-term future; days, not months.

Submit an Answer