At GEOLYTIX we have been hacking away for some time at an open source node.js web mapping framework: https://github.com/geolytix/xyz
XYZ is meant to run at scale on any platform with minimum fuss. We are riding the serverless hype train hard and should be calling release version 1.0 soonish.
Irgendwie fängt irgendwann irgendwo die Zukunft an; Ich warte nicht mehr lang.
A shipload of articles on ‘Going serverless this or that’ have been published in the last few months alone. I highly recommend the Serverless Series (What is Serverless?) by Nicolas Dao if you are not well versed yet or just looking for a comprehensive primer on this topic.
For XYZ we are targeting a Backend as a Service (BaaS) deployment. We already can deploy to any platform (as a service) and have recently made great advances in running the framework as a service (FaaS, also Function as a Service). It is here where Zeit Now comes to the crease.
Deployments via AWS Lambda or the Google App Engine should be possible as well but are yet to be tested. IMHO the Now service and Zeit’s presentation as well as pricing are currently unmatched. Did I mention that Zeit/Now is free!
Want your own GEOLYTIX|XYZ instance now?
First install zeit/now-cli.
Then you are good to deploy XYZ with zero configuration from our github repository.
now -V 1 geolytix/xyz
Voilà. Your deployment is ready. You can follow the link (should be in the clipboard) from the now deployment output and you will see the zero configuration map in your browser.
I recommend to set a fixed scale of 1 to your deployment in order to prevent XYZ having to load if not being accessed for a while.
I highly recommend to alias your deployment at this point. Otherwise your links will be dead once you create a new deployment. We use a NG!NX reverse proxy to forward calls on our domain to Zeit/Now deployments by setting the proxy forward to the Now alias.
I aliased the deployment which I just created with:
Want more freedom aliasing your deployments? It’s very easy and cheap to register a domain with Zeit/Now.
How does it work?
XYZ is build with a stack consistent of PostgreSQL, Fastify, JSRender, Node. Please read my article explaining the PfaJn stack in detail.
Workspace configuration and access control lists are stored in PostgreSQL tables. All spatial data at rest is stored in PostGIS tables.
While stateless, the hypertext transfer protocol is not session less. We use serverless signed JWT (JSON Web Token) to authenticate and verify requests. The token itself is retained in the client code and renewed at a set interval. We use the fastify-jwt plugin to sign and verify token which are received with non public requests.
This allows us to scale deployments without the need of a shared (or local) session store.
Once deployed to Zeit/Now… npm will fetch the required node modules defined in the package.json. Thereafter the build script will let webpack 4 do its magic and bundle the client application. We use the babel es2015 preset in order to provide IE11 compatibility. Once the build is complete node will start server.js. Prior to listening for incoming requests, XYZ will read the workspace configuration and register fastify plugins and routes.
Environment, Workspaces, configurations?
While it is pretty cool how quickly you can get your own web map deployment (~30 seconds). Maps are much more fun when you get to show your own data.
/open is a fully configured XYZ Now deployment with hex grids, vector tiles, cluster, bells and whistles.
Environment variables can be stored locally in an .env file or in the Visual Studio code .launch configuration. For deployments the environment variable can be supplied as -e options or secrets to the Zeit/Now Backend (aaS).
Environment variables hold data source connections, keys for 3rd party service provider (Mapbox, Here or Google), and the access control configuration for XYZ deployments. It should go without saying that these bits are quite sensitive and are asterisked in following example.
The access control configuration allows to deploy public or private instances of XYZ. Deployments are by default public but without an access control list (ACL) it will not be possible for an administrator to configure a live deployment via the workspace configuration view.
Without admin access the repository needs to be cloned and a workspace file must be stored in the workspaces directory before deploying to Zeit/Now from the local repository.
It is the workspace configuration which defines who has access to layers and locations and how the data is styled.
Not yet convinced… Zeit just announced a partnership with Cloudflare giving you best of class DDoS protection for the same ticket price (It’s still free). Of course there is SSL support out of the box (via Let’s Encrypt).
Need help? There is a Zeit/Now slack channel which answered all my questions to date.
Want to know more about XYZ? Perhaps you want to discuss custom features or need assistance with your deployment? Or you are looking for experts to get the best value from your (or our) data? Please let us know…