Latest Contributions by MichailMarinakis1

Hi all,  4 years ago, we created a production application based on arcgis js cli. During these years, we have created a lot of custom widgets for this app, following esri documentation, and we have migrated from: JS version 4.13 to 4.26, AMD to ESM, webpack 4 to 5, typescript 3.1.1 to 4.7.4, calcite maps 0.0.9 to calcite design 1.0.7 (partially, still on going), ...  Everything is working like charm and all the necessary tools to deploy to a production environment were included with the cli e.g. service workers, minification, PWA, etc. It saved us a loot of time! We considered that the cli was the tool to build production custom web applications. We want to start developing a new custom web app. We found out that the arcgis-js-cli is going to be deprecated (with a recommendation to use vite). We have been looking at the repo https://github.com/Esri/jsapi-resources: The custom widget sample has a deprecation flag (with a comment to use the UI component library of our choice (like react? so it is recommended not to use the UI framework of custom widgets? )) We noticed also a strong promotion of vite at most of the samples, instead of webpack. There are not so many typescript samples, even though it is promoted from the documentation here. What we are looking for is, a stable, "building for production", template to give us a boost start. So the question is, if we want to start creating a new custom web app, is there any official best practices/documentation/resources/recommended tools from esri?  I know there is no single answer, there are a lot of parameters to make a decision like that, just wondering if there is a consensus in the forum here or something that is already discussed between esri developers 😀 Thank you! @DasaPaddock  @AndyGup  @ReneRubalcava  @BenElan    ... View more

Hi all,  soo many articles have been written about this issue and yet, in our case, we are not able to solve it 😃. Here is our status: We have an ArcGIS Enterprise installation 10.9.1 (installed on Windows servers) for our test environment. Portal and federated hosting Server are on the same machine, datastore is on a separate one (we added datastore on a later phase). Datastore has relational and tile cache components installed. Portal and Server are behind a external load balancer, web adaptors are installed too, IWA is activated. Our security configuration allows only https protocol. We have installed valid certificates to Portal, Server, Datastore. The windows services for Portal, Server and Datastore, are running with the same Domain administrator account. This account has full access to all the windows folders with the software and configuration. The Server and Datastore machines are added as Trusted Sites (all the names of the machines, fully qualified, DNS names, machine name etc.).  All the related ports are open at the firewalls to all the machines and we have made sure that these ports are not used from any other application.  We have set the ssl certificates for the couch db too! That means that this couchdb url: https://<ds.fqdn>:29081/_utils/#login has actually a valid certificate! (idea: when we run the Datastore tool updatesslcertificate and a tile cache component is installed, then update the couchdb certificate too).  The above couchdb url can be accessed from hosting Server machine. The status of the noSqldatabase in datastore is OK when we validate from hosting Server. When we validate the federated hosting server from the portal, everything is OK. We are able to publish a Vector Tile layer.  We created a .slpk package, based on a LAS file, visualizing a point cloud. We can load this layer to ArcGIS Pro without any issues.  We try to publish this package either from the Portal directly, by adding an item, or from ArcGIS Pro.  In both cases it fails. There are two severe error messages in ArcGIS Server:  ERROR 001887: Failed to create couchdb database. Failed to create couchdb database.: Client tried to access password-protected page without proper authorization. (status code 401). Any recommendations would be extremely useful for us 😀   ... View more

Hi all,  we have created a web app based on custom builds, using webpack. We are managing the assets of JavaScript API (4.24.7) by copying the locally and setting the value of esriConfig.assetsPath to the right path. Everything works perfectly! We have decided to start integrating Calcite Design system (1.0.0-beta.92) to our web app. So far great experience! We are also managing the assets of Calcite locally. So we copy them to a location and then we use the function setAssetsPath to define the path. Everything works fine too (almost 😉 )! The JS API is using Calcite assets (1.0.0-beta.82 for the version we use). They exist in the folder node_modules\@arcgis\core\assets\components\assets.  Everything works fine overall but we noticed the following: All the calcite design components are using the assets from the JS API path and not from the setAssetsPath. Either the setAssetsPath doesn't work properly or there is a conflict between setting assetsPath for JS API and for calcite design? Again, everything works, but we are using different versions of assets. It might become an issue in the future? Since JS API is using calcite components, the css of the JS API includes already calcite styles. Eventually we are loading them twice (and from different versions), one css from calcite and once css from JS API. It makes sense, but I wonder if there is a more optimal way to do this.   So the question would be: Are there any best practices of integrating Calcite Design with JS API with custom builds?  There are very nice examples in github for Calcite Design and nice examples for JS API but I could not find any example with both of them together 😀 ... View more