Test and debug
Last updated
Was this helpful?
Last updated
Was this helpful?
Every action you take in Appfarm Create is instantly saved, meaning; your application is only a description of which UI components, logical building blocks, object classes, etc. are used in your application, as well as where and how they are used. Deployment to the development environment is instant and testing your App is simply a matter of navigating to a URL.
All Solutions in Appfarm come shipped with dedicated Development (DEV), Test (TEST), Staging (STAGE), and Production (PROD) environments. What is available in your Solution depends on your Appfarm subscription plan.
While using Appfarm Create to define your applications, all changes are automatically deployed to the Develop environment. Keep the apps client open in a browser tab to see your applications come to life as you use Appfarm Create UI Designer.
Navigate to https://SOLUTION_SHORTNAME-dev.appfarm.app, or use the button in the app bar to open the client for the active App.
If your App has only been enabled for small devices (mobile devices), you might need to open the debug tool in your browser to simulate a mobile screen resolution.
When testing your functionality, you will at some point need a way to debug your application logic. Appfarm comes with a set of built-in tools to help you tune your apps, and also diagnose problems.
Have a look at the section for more details. Here you will learn how to use the Developer Tools for Apps, as well as more advanced debugging.
If you want to simulate running the App from another device, such as a mobile or tablet, you could use the browser development tools. We recommend Google Chrome for this purpose. Chrome has a dedicated device button in the top-left section of the console. To open Developer Tools for Chrome, click F12, or navigate to Developer Tools from the settings menu of your browser. The browser built-in Developer Tools may also be used for .
If you are having a production issue: Have anything been deployed recently? If not, the amount of data used in the App or Service combined with the number of users or service executions is probably the issue. If no such thing is suspected, it might be a temporary infrastructure issue (visit , reach out to your point of contact, or email support@appfarm.io) If something has been deployed, you should start with an investigation of new or changed functionality you have deployed. It might also be that a new Appfarm version was included in the last deploy. If the latter is the suspected issue, post the issue in our , reach out to your point of contact, or email support@appfarm.io.
When testing Apps with different users, it sometimes occurs that the browser session is logged in with an incorrect user and that you do not have a "Logout" or "Signout" button available in your App.
You may log out 3 different ways:
1) Add a button to your App, and add an action with action node .
2) Navigate to the root (https://SOLUTION-HOSTNAME, for example https://thirtyfiftyinc.appfarm.app) and sign out using the top-left menu. Note that this approach only works if you have access to more than 1 app, otherwise, you will be redirected automatically to the (only) App you have access to.
3) Append /auth/logout to the URL (e.g. https://SOLUTION-HOSTNAME/myapp/auth/logout)
But how can you debug which data source is causing the issue? Here are a few steps to help you with this debugging:
Deployment is the task of applying updated versions of your application to various environments. After testing in the DEV environment, you might deploy the new version of your Solution to TEST, STAGE, or PROD environments.
All deployments are done in Appfarm Create. Click Deploy in the main menu.
Appfarm Create features one-click deploy - allowing you to deploy your changes to TEST, STAGE or PROD with one click. You may also roll back to a previous version in all of the environments.
You may take snapshots of your entire Solution (for example, Apps, Global Data Model - all configuration done in Appfarm Create) at any time. From the Deploy menu, expand the top left section Development, and select the Take Snapshot option. The snapshot will be listed below, and you may roll back to this (or another) snapshot at any time. Note that all changes done after the time of the snapshot will be overwritten.
Make a copy of your App (or Service) if you want to do some major changes. You are now able to experiment and develop on the copied App, without risking unrecoverable damage.
From the Apps list, hover over the App you want to make a copy of, click the more-button (𐄛) and then Make a copy. The App is now duplicated, without any references to the original App.
App Health is found in the top-right menu in Create when you are inside an App. It reveals incorrect or sub-optimal setup of your App, and you should revisit App Health regularly to remove errors and unused functionality. Please see for more info on App Health.
In some cases, your App might not load due to massive amounts of data, performance-heavy on data sources, or corrupt data. Database Connected Data Sources in App Data are loaded before the On App Load action executes, and before the App is displayed.
In the cases where loading initial data fails, you might get a timeout or minimal logging, since it often fails before the Developer Tools for Apps is loaded. Performing in the network tab may reveal this. But in general, if the app fails to load (before the On App Load action executes) without any errors in the log, the error is most likely due to large amounts of data or runtime functions on large data sources.
If you have a Staging environment: Deploy your app to Staging, enable , and see if it opens. If you do not have a Staging environment, you should consider enabling Devtools for Apps in Production for a short time.
Check if the data source has that are functions. If so, tick the option Initially Skip Function Properties. Remove the Limit Object Count / enable the data source, and see if the App loads. If it loads, the reason for the performance issues is one of the function properties. See step 2.2 (function parameters being large data sources with Initially subscribe to updates). But in general, you should not use other data sources as function parameters, if you are dealing with large datasources (>1000 objects)
Optional/Alternative: If the issue is inconsistencies or corrupt data, you will typically see a red error in the log when loading the App. A common error in the log related to this is CastError (read more ). You may need to inspect the data with GraphQL and update or delete the record(s).
If you want to debug services or test them manually, Appfarm comes with a . This has many of the same features as the DevTools for Apps, but it may also be used to trace and se execution log for incoming requests, or the log when a Service is executed by a schedule.
If a Service works when you are executing it manually in the , but not when executed from a Schedule (or when triggered by a third party), the issue is most likely related to the of the Service Account. The Service Account needs to be a member of a Role, with itself, and the used by the Service, and it must have to the Environment.
Service Health is found in the top-right menu in Create when you are inside a Service. It reveals incorrect or sub-optimal setup of your Service. Please see for more info.