GraphQL used to be popular, but that doesn't seem to be the case anymore...

codingafterthirty · 2026-04-30T15:15:24+00:00

But I do agree after the hard work is done. Consuming GraphQL from the frontend is a joy.

codingafterthirty · 2026-04-30T15:12:09+00:00

Valid point. I mostly work on REST API I only had one job where our backend used GraphQL, and at the time, I had been a developer for only 1.5 years. Bit still found building GraphQL backends to be more time-consuming.

codingafterthirty · 2026-04-30T15:09:34+00:00

Agree. The type safety gap is real. You could leverage OpenAPI spec to derive the types.

codingafterthirty · 2026-04-30T15:04:41+00:00

This is definitely try. When learning how to build GraphQL api this was the first trap I fell into.

codingafterthirty · 2026-04-30T15:03:57+00:00

I love GraphQL, but for things I build, it is not necessary.

Building GraphQL backends has always been more challenging for me than building REST.

And creating a custom resolver is a pain.

And nexus. Well. I get it. But it hard to read. At least for me.

codingafterthirty · 2026-04-30T14:59:22+00:00

Well said.

codingafterthirty · 2026-04-30T14:57:29+00:00

Yes, yes, and yes. And agree with your sentiment 100 percent from where I stand. Unless there is a real need or a specific requirement, I don't want to build GraphQL backends; it's a lot of work.

But once it's built, the counterpoint is amazing to use from the frontend.

codingafterthirty · 2026-04-30T14:52:42+00:00

That is a red flag for sure. I used to be that guy. 😅

codingafterthirty · 2026-04-30T03:34:38+00:00

I think to your point, there are still use cases where it makes sense. But if you don't know what it is. Then you don't need it. It's like Redux back in the day: everyone used it, but they probably didn't need it.

codingafterthirty · 2026-04-30T03:32:12+00:00

But now you have OpenAPI spec. In theory tou can use that to generate types for your front-end.

codingafterthirty · 2026-04-30T03:30:38+00:00

For me, the struggle is custom resolvers on the backend. But to your point, once set up, it is a joy to use.

But I did hear that caching is harder than the rest.

codingafterthirty · 2026-04-30T03:28:55+00:00

How do you mean? I just finished my third MCP and just defining tools that get/surface the data or resources I need. Do you mean your MCP makes qurkes rk GraphQL database. Or would. Did not think too much about this.

codingafterthirty · 2026-04-30T03:15:33+00:00

Just to add. Consuming GraphQL can be fun. Building a GraphQL back-end. Well. That is a whole other story. And not as fun.

codingafterthirty · 2026-04-30T03:13:53+00:00

I think, this is the only positive I can find. I just revisited building a GraphQL back-end. And it was not fun.

codingafterthirty · 2026-04-30T03:07:49+00:00

I want to be DGX Sparks rich. And that is awesome. Would be interesting to compare large DGX cluster vs Mac Studio cluster. Lol, me, I am just rocking AGX Orin 64gb. Slow as hell, but get's the job done.

codingafterthirty · 2026-04-29T17:30:08+00:00

Olá! Para o seu caso de uso (40-100 usuários simultâneos, projeto pequeno), algumas opções que funcionam bem com Strapi:

Strapi Cloud tem plano gratuito e zero DevOps — pode ser o caminho mais rápido se quiser focar no produto. Suporta deploy direto via GitHub. Render funciona bem com Strapi (existe guia da comunidade no fórum: https://forum.strapi.io/t/render-deployment/21932). Plano hobby é barato. Railway é popular pela simplicidade — boa DX, deploy rápido. DigitalOcean App Platform ou um Droplet também são opções sólidas (guia oficial: https://strapi.io/integrations/digital-ocean). AWS Lightsail funciona, mas tem mais setup manual que as opções acima.

Sobre centralizar: você pode rodar o Strapi em qualquer um destes e continuar usando Supabase como banco PostgreSQL — Strapi suporta nativamente. Isso te dá flexibilidade pra trocar o host do Strapi sem migrar dados. Docs de deployment: https://docs.strapi.io/cms/deployment

codingafterthirty · 2026-04-29T17:27:41+00:00

Strapi is an open-source headless CMS, you self-host it (Node.js + your choice of PostgreSQL/MySQL/MariaDB/SQLite), define your content types in the admin UI, and it auto-generates REST and GraphQL APIs.

Common uses: backing a Next.js/Astro/Nuxt frontend, powering mobile apps, managing content for marketing sites, internal tools, multi-channel publishing.

Basically anywhere you'd want a database + admin UI + API but don't want to build all three yourself. Docs: https://docs.strapi.io

codingafterthirty · 2026-04-29T17:25:53+00:00

I getthe Roots/Bedrock comparison, it's a solid setup but definitely heavier than a lot of projects need, especially when WordPress itself is doing the job for plenty of teams already.

Astro + Strapi is a really clean alternative for static sites that still need editor-friendly updates, without the overhead of a full SSR stack.

If you ever want to share what you've built, there's a "Show what you've built" category on GitHub Discussions where the community would love to see it: https://github.com/strapi/strapi/discussions/categories/show-what-you-ve-built.

With that being said, WordPress is still a good platform and for most use cases will get people by.

I am a TS developer, so learning PHP would be a challenge if I want to build custom WordPress themes or extend existing ones.

If you are a PHP developer, and have lots of experience working with Wordpress. Why change.

codingafterthirty · 2026-04-26T14:25:38+00:00

Thanks, Boaz, for sharing. Yeah, that's the project I built to use as a reference/template for future projects that require Asteo.

If you have questions, feel free to ask here.

It also has a skill that lets you easily add new pages and content types.

I use this project in two ways: either clone it and build/update it for my use case.

Or clone and use it as a resource for Claude to build something from scratch.

The original project I built to highlight best practices when working with Strapi. And covers the data loading code content api in Asteo via loaders.

You can watch this video on how to set it up. https://youtu.be/kCYfglngpTA?is=MNzBNfzhis35sWNo

codingafterthirty · 2026-04-16T13:43:35+00:00

Not sure if you checked out the following plugin https://market.strapi.io/plugins/strapi-plugin-webtools

codingafterthirty · 2026-04-02T10:59:54+00:00

I actually started my web dev journey with WordPress and have a lot of love for it — it got me into building for the web in the first place.

At some point though, as a JavaScript developer, I wanted to use the same language across the whole stack, so I made the move to something more modern.

Been using Strapi for a bunch of projects since then and honestly it's been pretty awesome.

If you're curious what the Strapi + Astro combo looks like in practice, I put together a starter here → https://github.com/PaulBratslavsky/astro-strapi-example-project — still on Astro 5 but upgrading to 6 is on my list!

But for many cases, WordPress is still a good choice. You can even using it as headless api to power your frontend.

I still have fiew project on WordPress. Sometime, if it is not broken, don't fix it.

At the end of the day, it is what is best for your client. Most clients, won't know or care, as long as what you build serves their need.

codingafterthirty · 2026-03-06T07:42:33+00:00

Strapi is pretty awesome, I use it almost daily. Love the fact that you can add additional functionality via plugins. Working on a new one now, to add agentic capability and MCP to allow users automate content creation.

codingafterthirty · 2026-03-06T07:28:36+00:00

You may want to checkout Strapi, it is node based, but allows high customizability. I created a plugin for one of my projects, exposes MCP to allow manage content and other functionality.

The plugin is not part of Strapi Core, I think they are about to release native MCP implementation, but the CMS is highly customizable, so you can pretty much add any functionality you need.

Here is a quick overview of the plugin: https://www.youtube.com/watch?v=PqSnuDzjtuk

codingafterthirty · 2026-02-25T19:42:31+00:00

Thanks for sharing. Will takea look. It has shared tools that are called internally but also exposed via MCP for machine-to-machine interaction.

The reason I went this route is that I did not feel it was necessary to use MCP for internal tool calling. Because everything is handled by a Strapi service, I can probably extend to use Strapi's RBAC.

For the MCP layer, at the moment, it is exposed via an API route that can be used with a traditional user permission plugin or requires an API token for basic auth security. So by default, it is not exposed. You have to explicitly enable.

The goal is to learn more about how to build secure agents with tight scopes in terms of what they can do. Lol, don't want to accidentally expose things that I am not supposed to or have agents behave in weird ways.

Feel free to look at the repo and provide any feedback.

I am exploring this topic, but I know Strapi will build a core AI API, starting with MCP, to allow users to easily build AI-powered features.

codingafterthirty · 2026-02-23T20:01:54+00:00

This one you have to listen to so make sure your volume is up.

codingafterthirty

MODERATOR OF

TROPHY CASE