Hi everyone,
I’m currently working on a small web project and I’m splitting my workflow between the backend and frontend since I’ll need a “heavy” processing component for automated spatial operations.
This part mainly involves running scripts that perform spatial tasks such as calculating point distances, handling geometry intersections, and updating labels based on spatial results.
Apart from that, the project also includes the usual web elements — a standard database, content pages, multimedia, etc.
So far, I’ve been considering Strapi for the backend and Vercel for the frontend, but I suspect I’ll need an additional service to handle the spatial processing layer.
Has anyone here worked on something similar (ideally keeping costs low)?
What tools, architectures, or workflows would you recommend?
Any feedback or corrections to this general approach are more than welcome.
Thanks in advance for any advice or experiences you can share! 😊
Top comments (4)
Hey! While I have not worked on something similar I know a few Strapi users who have leverages plugins for similar use cases i.e market.strapi.io/plugins/@gismark-... or market.strapi.io/plugins/strapi-le...
Hey Victor, that is really interesting and useful, appreciate it!
It really depends on how much data you’re processing and how complex the spatial operations get.
For light or moderate workloads, your setup can stay simple:
If some of the work is lightweight (like simple distances, buffers, or intersections on small datasets), you can even run it client-side with Turf.js — it’s perfect for quick spatial logic without extra infra.
For heavier or long-running tasks, you can introduce a job queue later (e.g., Redis + worker) so your processing runs smoothly without blocking the main app.
Since you're optimizing for low cost and splitting Strapi/Vercel, the decision really comes down to two questions:
How big is the geometry, and does it change per request? Point distances + intersection tests on a handful of features → Turf.js client-side is genuinely fine and free (as others said). Thousands of features, or you need to repeatedly query "what intersects this" → that belongs in a spatial database, not the browser.
Where does the data live? If it's your own data, the cheapest "additional service" is usually not a new service at all — it's PostGIS (the extension on a Postgres instance you may already be running). ST_Distance, ST_Intersects, and a GiST index cover exactly the "distances / intersections / label updates from spatial results" you described, server-side, for the cost of a Postgres box. Strapi sits in front of it.
Rule of thumb: client-side (Turf) for display-time math on small result sets; PostGIS for anything you'd otherwise loop over or need indexed. A whole separate spatial microservice is usually the thing you don't need.
One caveat: if the spatial layer is actually external live data (traffic, road conditions, POIs) rather than your own geometry, it flips — then you're better off hitting an API that already does the spatial work server-side than ingesting and indexing it yourself (road511 does this for road/traffic data, for example). But for your own geometry, PostGIS is the low-cost answer.