I saw this tweet today from Lyzi Diamond and I found the question intriguing. My answer was reference back to one of her posts, concerning the use of link relations to add GeoJSON data to Leaflet.
What has been your biggest “a-ha!” moment while learning mapping technology? What resource gave it to you? #gistribe
— Lyzi Diamond (@lyzidiamond) September 16, 2015
The post is an oldie but a goodie and I didn’t reference it to butter Lyzi up. Although I have moved on from the technique she describes in that post (and you can follow the post updates to see that she has, too), it started me down a line of thinking that has changed the way I approach my consulting work.
As something of a greybeard (literally and figuratively), I can sometimes fall into the trap of relying too heavily on “design patterns” that are really nothing more than tried-and-true habits. There’s nothing wrong with using patterns per se, as long as you remember to occasionally look up to see what else is going on. I had unknowingly fallen into the pattern of assuming “map server” (term used generically) for any web mapping application I was designing. The options for that place in the “stack” were pretty varied but I didn’t question the need for one so much as which one I would use.
Lyzi’s post got me exploring the concept of building interactive mapping applications with static content, as well as when that would be appropriate, and identifying the thresholds and parameters beyond which you would need to go with a map server. I’ve come to realize that most of the workflows of my customers over the years would have lent themselves well to such an approach, if the technology had been there to support it.
Where it is appropriate to use static content, there are even distinct advantages for performance, caching, and security. For example, not having a live link to a database server and not having additional mapping technologies to patch and maintain makes IT staff very happy. And, of course, you’re letting web servers do what web servers do.
So, essentially, my first question when starting a mapping application changed from “What map server do we use?” to “Do we need to use a map server?” If I can prototype mapping capability using only GitHub or NGINX, I probably proceed without a map server. It helps that new technologies are coming online all the time that continue to make it easier to proceed without one.
Map servers do provide some compelling capability and should be considered in any proper system design evaluation, but it should no longer automatically be assumed that one is required in order to deliver a rich interactive web mapping application.
A somewhat unrelated observation on map servers: I have spent a lot of time and effort to provide a dynamic, collaborative experience with geographic data, only to hear “Uh… Can you just send us a shapefile?” time and time again.
With so many things in life, you get out of it what you put into it. With map servers, you only get out of it what your clients get out of it; And too often it adds up to naught.
I agree. Most of my customers run through some form of a publication/validation process before letting maps go live. As a result, a live link really isn’t so valuable as they are not updating their published data/maps transactionally. That seems to be the most common break point I’ve found in deciding between static content or a map server. Sometimes, environmental constraints, such as a need to support OGC specs, will take us there as well. But I’m generally finding more and more cases where geomiddleware just isn’t needed.