Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Development VS Production deployments? #3298

Closed
Subaku opened this issue Jul 2, 2019 · 3 comments
Closed

Development VS Production deployments? #3298

Subaku opened this issue Jul 2, 2019 · 3 comments
Labels
developer-experience Issues affecting ease of use and overall experience of LB users

Comments

@Subaku
Copy link

Subaku commented Jul 2, 2019

I'm wanting to know the key differences in deploying my lb4 app in a development environment vs a production environment. Was wanting to make sure I didn't miss anything as I could not find any examples detailing things to look out for.

  1. Turning off the API explorer. I assume this is a good idea but how? I've attempted the following in my index.ts but the explorer is still working.
export async function main(options: ApplicationConfig = {}) {
    options.rest = {
      apiExplorer: {
        disabled: true
      }
    };

    const app = new MyApiApplication(options);
    ...
  1. Running the app via node I assume setting an env variable "ENVIRONMENT" that I can read and use to load different configs is the way to go? Are there best practices that lb4 recommends for using different configs based on environment?
  2. Anything else I'm not thinking about.

Appreciate the guidance!

@Subaku Subaku added the question label Jul 2, 2019
@dougal83
Copy link
Contributor

dougal83 commented Jul 3, 2019

+1 Would be great to have a best practices section on the documentation for production hardening recommendations(if any).

@hacksparrow
Copy link
Contributor

@Subaku apiExplorer.disabled was introduced to disable redirection to the externally hosted Explorer app in older version of LB4. It is no required any more in the later versions. I agree, it is a confusing property name.

To disable Explorer, comment out the code loading and mounting the Explorer in application.ts.

import {
  RestExplorerBindings,
  RestExplorerComponent,
} from '@loopback/rest-explorer';
...
this.bind(RestExplorerBindings.CONFIG).to({
  path: '/explorer',
});
this.component(RestExplorerComponent);

@raymondfeng @bajtos apiExplorer.disabled should indeed disable the Explorer.

As of today, I am not aware if we are doing anything based on the setting of an environment variable. However, since LoopBack uses Express underneath, if you set NODE_ENV=production, all the Express optimizations will kick in.

@hacksparrow hacksparrow added the developer-experience Issues affecting ease of use and overall experience of LB users label Jul 3, 2019
@bajtos
Copy link
Member

bajtos commented Jul 9, 2019

Production deployment is a topic that we haven't researched in detail yet, see #1054

Turning off the API explorer.

At the moment, API Explorer is implemented as a standalone component. It is typically enabled by the following line in your Application's constructor:

https://github.com/strongloop/loopback-next/blob/b764835d4afec738102cac56d88225e29fe50389/examples/todo/src/application.ts#L27

Until we implement a more robust solution, you can disable the explorer for example this way:

const env = process.env.NODE_ENV || 'development';
if (env === 'development') {
  this.component(RestExplorerComponent);
}

Anything else I'm not thinking about.

If you have configured the error-response handler to return full error in HTTP responses, as explained in https://loopback.io/doc/en/lb4/Sequence.html#handling-errors, then make sure to disable that behavior in production.

app.bind(RestBindings.ERROR_WRITER_OPTIONS).to({debug: env === 'development'});

Note that debug is disabled by default, so your application is safe if you are not providing any custom ERROR_WRITER_OPTIONS ✌️

@Subaku Subaku closed this as completed Jul 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer-experience Issues affecting ease of use and overall experience of LB users
Projects
None yet
Development

No branches or pull requests

4 participants