This content originally appeared on DEV Community and was authored by Luiz Gonçalves â
Let me tell you a story about trees, side-projects, and why I thought it'd be a good idea to build an API that plants stuff.
đą Why I Built This (and What It Actually Is)
So... Iâm one of those people who loves shipping things. And also, I love trees. Always did. Thereâs something grounding about forests. Theyâre quiet, slow, and do their job without drama. I canât say the same about most of my tickets on Jira.
So I asked myself: how can I contribute to reforestation without quitting my job or becoming an Instagram eco guru? And then came the idea: We Build Forest (WBF) â a platform where companies (or people) can plant or adopt trees via API calls. Thatâs it. You call an endpoint, and somewhere in the world, a seed gets a chance.
Itâs a side-project, built mostly in my free hours with help from some good folks â devs, PMs, environmental partners. Real people. Real impact. Not a greenwashing gimmick.
The win-win is real:
- Companies get a conversion boost (âwe plant a tree for every Xâ hits hard)
- Users feel like theyâre doing something meaningful, which they are!
- I take care of the boring infra stuff and make a small margin
âď¸ Tech Stack
The stack is solid, if you ask me. I didnât want this to be a toy project that dies with the first webhook.
NestJS for backend (GraphQL + WebSockets where needed)
MySQL with TypeORM â relational and boring (good)
Redis + Redlock â because yes, queues need locks
SQS + SNS â because things are async, always
Vite + Tailwind â WIP - frontend is SPA, fast and clean
Prometheus + Grafana
No AI here for now. Just trees and messages.
đď¸ Multi-tenancy
Every client has their own API key, rate limit, webhook setup, and visibility scope. Thatâs our basic multi-tenancy.
But here's where it gets spicy: the platform has region-aware endpoints:
api-us(for North America)api-br(for Brazil)api-jp(for Asia)
This isnât just for latency â itâs also about compliance. Some countries want local logs, local data, or slower bureaucracy. So yeah, if a US client sends a request to api.web.whatever, itâll still work... but might be slower, or even trigger warnings depending on the tenant's config.
In a perfect world, everyone hits the right region. In reality, we just try not to break anything.
đ˛ Trees Arenât Instant (and Thatâs Okay)
One thing I had to embrace early: tree planting takes time.
Youâre not buying a t-shirt. Youâre claiming that someone, somewhere, will plant a tree. Maybe in a few days, maybe in two weeks.
So hereâs what I did:
Each tree is an entity in the DB
It can be partially claimed (10%, 20%, until it hits 100%)
Once full, itâs marked for planting and linked to a partner NGO, which had previously agreed on planting X trees, regardless of the supporters.
Webhooks fire to notify the client
We generate a nice little and legitimate PDF certificate and store it in S3
The whole system is modeled around asynchronous reality. Nothing blocks. No one waits for a shovel to hit dirt.
đ¸ PDF Certificates: The Unexpected Boss Fight
Certificates are a must here, as many people will use them for tax exemptions, proof of donation, etc. People love the certificates too; they want to share them on their socials. But man, they are expensive to generate and store.
Right now:
- We create PDFs per adoption
- Store them in S3, accessible via link
But long-term, Iâll migrate stale ones to Glacier. I already tag them by access date. Itâs just a matter of tuning the lifecycle.
Side-projects teach you that every cost matters. Especially when you're not funded.
đ Monitoring and Sanity
This thing runs 24/7. People hit the API. Stuff gets queued. Trees are claimed.
So yeah, I need eyes on it:
Prometheus tracks per-tenant metrics
Grafana shows cert generations, queue depth, webhook retries
I can tell when a partner in Brazil is slow. Or when someone is spamming test calls. Transparency is part of the promise.
𧪠Tests, Because I Like Sleep
Just because itâs a side-project doesnât mean it can break. Iâve got tests on:
Credential validation
Queue processors
Webhook delivery
Redlock handling
Everything has cursor rules to force me to test before merge. Not because itâs trendy â because I donât like waking up to alerts.
đ Whatâs Next?
Still early days. No public launch yet, just a landing page with some mock data... But some folks are already testing, and itâs working better than I expected.
The roadmap:
Public-facing dashboard
Partner onboarding flow
Shopify/Stripe plug-ins
Bulk operations for marketplaces
And maybe â just maybe â turn it into a SaaS with real traction.
đ Final Thoughts
Iâm not trying to save the world. But if I can plant some trees while helping companies add value to their product? Thatâs a start.
If youâre a dev, founder, or PM and this sounds like something youâd use â letâs talk.
And if you just wanna see some code â GraphQL schema? Queue handler? PDF gen script? I got you too.
Letâs reforest the internet. One webhook at a time. đ˛
This content originally appeared on DEV Community and was authored by Luiz Gonçalves â
Luiz Gonçalves â | Sciencx (2025-11-03T19:38:02+00:00) Building We Build Forest: A Side Project to Reforest the Planet – with some JS. Retrieved from https://www.scien.cx/2025/11/03/building-we-build-forest-a-side-project-to-reforest-the-planet-with-some-js/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.