we have a current architecture of FlexViewer and part ARCGIS Flex API based custom tool, that's sitting on a IIS server to draw zones.ESRI is migrating to ESRI Javascript API and we have a two options of either using the web app builder or use plain vanilla arcgis js api. My TA is suggesting that we use, plain vanilla arcgis js api, and to load the esri js libraries and host our own version dojo libraries using the dojo module loader. Also, he is suggesting not to point to any ARCGIS URL directly from the client side, but repoint all the arcgis layer url's to a Java layer web services url , that would mirror the ARCGIS rest services and he wants all the coded domains in a separate table and all the client side configuration(urls and properties file) to be stored in Oracle table. He thinks it would give him better control in the Java side and it would align with his architecture(non ARCGIS based) It feels to me we are over engineering a simple solution. I'm looking for community developer inputs, on why someone would want this. It seems like an overkill.
0
votes
1 Answers
1
votes
From experience writing lots of custom JavaScript is often unnecessary and will give you the headache of maintaining it moreover ESRI provides lots of functionality out of the box and where possible I would stick to using the "vanilla" functionality provided, it's also worth noting that the ArcGis API is built on top of Dojo and the module loader works really nicely with their API.
As for "he is suggesting not to point to any ARCGIS URL directly" does he mean service endpoints? Because you would query the publish layers regardless.
It also worth reading this - https://www.esri.com/~/media/Files/Pdfs/products/arcgis-platform/architecting-the-arcgis-platform
Hope that helps!
