Almost every application requires some degree of server-side business logic. This could include anything from cleaning data going to or coming from the server, connecting to external, third-party APIs, or doing some complex, asynchronous processing that is best kept off the client (to name just a few examples).
Sounds great, right? Well, the caveat is that developing and testing these can be a bit complex. For example, local testing requires that you stop and start the runtime each time you update your code. Plus, if you are interacting with data that lives in Kinvey, this data isn’t available in your local tests. Even still, once you deploy the code to the cloud, debugging can be limited – some errors don’t display in the most useful manner (showing up as a general business logic failure) and it’s not easy to see anything you may write to the console, which can be hugely useful during development (you’d need to check the Flex Service logs by running
kinvey flex logs from the CLI and parsing through the responses).
Of course, you know there’s a solution, right? I mean, if there wasn’t this would be a terrible article. So without any further hesitation, let’s look at a productive FlexServices development setup.