Library support for browsers

[ajturner]

Starting an open issue to discuss the action from #73

There are numerous use cases for interacting with our GeoServices API that are not Cartographic. We need support in Cedar, as well as projects with US Census citySDK-arcgis

Requiring Leaflet or JSAPI is overkill and arguably a simple library is what they should include rather than vice versa.

If this project doesn't want to do it, then we should make a new one that does and call this geoservices-node

[JerrySievert]

i would support renaming this geoservices-node.

[ungoldman]

sure why not 👍

[nixta]

👍

[ajturner]

And building a new library just for browser JS? Can we reuse code or modules?

[patrickarlt]

I would love to simply build an arcgis.js library for specifically working with ArcGIS services (node or browser) that isn't tied to the geoservices spec. I think its badly needed and could be consumed by Esri Leaflet.

[ajturner]

@patrickarlt I'm not clear what you mean in talking to ArcGIS services but not the geoservices spec? They are the same thing.

It should be very simple. Chain methods that that build HTTP requests and do error handling. It's mostly verifying good inputs, handling the oddity of 200 status but body is an error, and niceties such as pagination.

[patrickarlt]

No one cares about "geoservices" as a concept its a dead spec, ArcGIS remains the only implementer. Users want something to talk to ArcGIS and abstract the API nicely for them they dont care if it is "geoservices" under the hood.

If we are being really strict about it "geoservices" don't technically support things like routing or f=geojson

From a pure branding and library name perspective I'm really interested in simply building arcgis.js and making it as good as possible and not caring about "geoservices."

[ungoldman]

The man has a point

[ajturner]

Ok - so we're discussing branding.

ArcGIS has a broad set of APIs. Curious how you envision scoping and demarcating between them:

• ArcGIS portal content management - items, users, groups
• ArcGIS feature/image/map/stream/locator services
• ArcGIS visualization (maps)
• ArcGIS HTML UI components
• JavaScript bindings to ArcGIS desktop/pro

Does ArcGIS.js have all of this? Or ArcGIS-portal.js, ArcGIS-services.js

This was one reason why I suggested geoservices as a way to make it clearer.

[JerrySievert]

some of the code may be reusable, but before even thinking about that, i'd suggest stepping back and taking a look at the patterns. all of the code in this repo uses the node.js pattern of callbacks (aka, callback hell). this may not be optimal in the browser, and thus any code that was reused would need to be refactored to reflect this.

so, beyond branding:

• method signatures
• build strategies
• testing methodology

[ajturner]

Thoughts on writing in ES6?

I'm agnostic on build and testing - suggestions?

[jgravois]

leaving this issue open because we have a new project brewing.

[ghost]

@jgravois which topics will the new project cover?
Is it going to be a version of geoservices-js that also browsers may use? (I've seen the minified version of issue #115 )
It would be nice if you could share a bit of roadmap. 👍 🙏

[jgravois]

@luciob great timing! today we've open sourced a brand new project usable in both Node.js and modern browsers. 🎉

arcgis-rest-js currently supports making both anonymous and authenticated requests to ArcGIS Online and Enterprise and includes wrappers for geocoding and interacting with ArcGIS Online/Portal items. the microservice architecture will allow developers to install and consume only what they need.

You can check out our open issues to see discussions pertaining to the design of upcoming packages. The project has already seen contributions from our PDX and Washington DC R&D labs and Professional Services and will be consumed in https://developers.arcgis.com and https://hub.arcgis.com.

Now that the work is open source, we hope to broaden the collaboration with all our great customers as well, so if you have questions, comments or concerns, please reach out and help us flesh out the doc.

FAQ

npm packages will be landing in the @esri namespace shortly.