I Thought Google Maps Directions API Was Enough — Until It Wasn’t

When I started working with the Google Maps Platform, I thought building a dynamic route system would be straightforward.

I was wrong.

The Requirement

The feature sounded simple at first:

• Users can add more than 25 to 50 markers.
• The route should automatically update when:
• A marker is added
• A marker is removed
• The route is dragged
• The route must always follow real roads.

Naturally, I used the Directions API with the DirectionsRenderer.

It worked beautifully.

Until it didn’t.

The 25 Waypoint Problem

Everything was fine — until users started adding more markers.

That’s when I hit the first major limitation:

The Directions API only allows 25 waypoints per request (including origin and destination limits depending on plan).

And my application allowed users to create routes with any number of markers.

Suddenly:

• Routes failed to render.
• The frontend logic became messy.
• Errors started appearing for larger routes.

This wasn’t a bug.

It was a limitation.

My First Solution: Splitting the Route

To bypass the 25-waypoint limit, I implemented a workaround:

• Split markers into batches (chunks under 25).
• Call multiple DirectionsRenderer instances.
• Stitch them together visually to look like one continuous route.

It worked.

Kind of.

New Problems Appeared:

• Managing multiple renderers became complex.
• Maintaining route continuity wasn’t clean.
• Updating markers dynamically required recalculating multiple segments.
• Performance started degrading for large routes.
• Dragging behavior became inconsistent.

At this point, I realized I was fighting the tool instead of using the right one.

What I Discovered Later (But Haven’t Implemented Yet):

Later, I discovered the newer Routes API.

Get Siddharth Shinde’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

And this changed everything.

Unlike the client-side DirectionsRenderer, the Routes API:

• Runs on the server side
• Handles waypoint optimization
• Is designed for more advanced routing scenarios
• Avoids the strict 25-waypoint limitation issue in the same way

Instead of rendering the route directly, it returns:

• Optimized waypoints
• Encoded polylines

From there, I could:

• Decode the polyline
• Draw it manually on the map
• Ensure it followed real roads

No DirectionsRenderer needed.

But There Was a Catch

One major feature was missing: No built-in drag-to-edit route like DirectionsRenderer provides.

That was a big trade-off.

However, I realized something important:

You don’t actually need route dragging — you need route updating.

So instead of dragging the path directly, I implemented:

• Marker drag events (dragend)
• Re-calling the Routes API
• Re-rendering the polyline dynamically

The user experience remained smooth.

And the architecture became much cleaner.

What I Learned

What This Experience Taught Me

1. API limits directly impact system design.
2. Workarounds can increase technical debt.
3. Quick solutions may not scale long-term.
4. Researching alternatives early can prevent rework later.

Final Thoughts

At first, I thought this was just about plotting routes.

But it turned into a lesson about:

• Understanding API limitations early
• Choosing architecture based on scale
• Not over-engineering client-side hacks
• Knowing when to switch tools

If you’re building a scalable routing system with dynamic markers, carefully evaluate whether DirectionsRenderer is enough — or whether the Routes API is a better long-term solution.