❗ This is a production repository. Be careful to update the master branch of this repository because it is published as deployment source for Azure App Service https://tlvgraphql.azurewebsites.net
Launch customized Graphiql interface for this server via this endpoint. You shoud authenticate youself as TLV Digitel customer. Explore GraphQL CRM schema from 'Docs' tab on upper rigth. On the left side of Graphiql you can compose various GraphQL queries. You can enrich these queries with variables prepared on down left bar.
When ready, copy the query (possible with the variables) to your client and use the GraphQL tool appropriate for your language. We have a sample of such client written in React.
The actual endpoint of this service for GraphQL POSTs is /graphql (without i). Other HTTP verbs (GET, OPTIONS, PUT etc.) are not served by GraphQL. Use (authenticated) queries and mutations for updates or reads.
This is reference implementation of GraphQL Server for TLV CRM exposed by its API. It is implemented with Apollo NodeJS packages. Invoking GraphQL server requires the authentication that could be performed against the TLV authentication endpoint (better be called /me) or interactively from this page. Currently, the authentication is based on the records of registered Digitel customers. The obtained authentication token (JWT) should be passed to GraphQL server with Authorization header, however, GraphQL Server does not validate the passed token. It just forwards the token down to the wrapped API. Since CRM API is actually managed by Azure API Management, the token is validated there in the policy associated with API.
This project consists of a server and a client parts.
The server side that actually implements GraphQL Server functioality does not require any building steps: it runs under Node as simple as npm run start or, under Azure, it runs automatically with iisnode since server.js is configured to be the default script in web.config.
Client side of this project is customized UI of famous GraphiQL. It adds authentication to GraphiQL for Digitel customers. For development environment, build it as following:
npm run client:buildyarn run client:build
In either case, this buils should create the bundle.js file in ui/assets directory.
For production environment, build the source as following:
npm run client:build:prodyarn run client:build:prod
Under Azure, run these scripts from Kudu console.
Production build is based on process.env.NODE_ENV variable that actually is set up within webpack build-in DefinePlugin in production configuration config (webpack.prod.js).
HTML file index.html from ui directory refers to created bundle. Both files client files - index.html and bundle.js - are served from main server Express code as statis folders.
This project uses GraphQL v0.12.3 that has an issue 😱 for production build. This issue seems to be addressed in PR#1174 but at time of release (Dec. 2017), it has not been merged in GraphQL version. One way to get rid off this issue is to disable mangling for GraphQL build with webpack:
plugins: [
...
new UglifyJSPlugin({
sourceMap: true,
uglifyOptions: {
mangle: false
}
}),
] Although this increases the size of the bundle for about 40Kb, this will be eliminated once GraphQL merges 🙏 the mentioned PR.
This site is tested to run under NodeJS ver. 8.9.0/1/3. When running on Azure hosting, the requirements for NodeJS version are expressed in Application Settings section of Azure Portal:
WEBSITE_NODE_DEFAULT_VERSION = 8.9.0
On Azure this site is hosted under IIS with iisnode. By default, iisnode ignores scripts in package.json and assumes the main entry point to the site is server.js as specified in web.config. According to this defaults, server.js of this project serves as a hook to run JS code within babel. This configuration is mirrored in included package.json and could be used for local runs:
npm run start
The actual code for the site is inside App.js.