-
Richard Towers authored
It's often nice to be able to work on front end issues without having to have a full backend up and running. This is particularly true of paas-admin, because you need a correctly configured Cloud Foundry, UAA, paas-accounts, and (to some degree) paas-billing to be running before you can click around in paas-admin. By adding a "stub" API we can run the frontend in isolation from a "real" backend. This is also useful if you're working without an internet connection. There's not too much code needed to get this to work, because we already have most of the API responses we need mocked out for various tests. I've used TypeScript for the stub-api so it's consistent with the rest of the app, and so we can import cf.test.data.ts from the existing codebase. I've taken a direct dependency on ts-node so you can run the stub-api without having a separate compile step - this isn't a new dependency because we already depend on it through ts-mocha.
f0f55c08Richard Towers authoredIt's often nice to be able to work on front end issues without having to have a full backend up and running. This is particularly true of paas-admin, because you need a correctly configured Cloud Foundry, UAA, paas-accounts, and (to some degree) paas-billing to be running before you can click around in paas-admin. By adding a "stub" API we can run the frontend in isolation from a "real" backend. This is also useful if you're working without an internet connection. There's not too much code needed to get this to work, because we already have most of the API responses we need mocked out for various tests. I've used TypeScript for the stub-api so it's consistent with the rest of the app, and so we can import cf.test.data.ts from the existing codebase. I've taken a direct dependency on ts-node so you can run the stub-api without having a separate compile step - this isn't a new dependency because we already depend on it through ts-mocha.
Loading