Strapi isn't just a CMS right? Is it not also a fully fledged backend web framework (like Django)?

Strapi advertises themselves as a CMS, but I feel it’s much more than that. It feels like a backend web framework like Django. We can create our own APIs with routes & controllers. This means we can create custom endpoint URLs, and custom logic to handle each request. We can query whatever data we need from our database too.

I’m not very experienced with backend, so I’m posting this here in case I’m missing something and someone can clarify why Strapi is mainly marketed as mostly a CMS rather than a backend web framework.

Thanks!

1 Like

Django is a backend framework written in python.
Strapi is a backend framework written in Javascript.

Both are Backend frameworks, though the big difference here is that Django has more batteries included.
In django you can render views and pass data to the “frontend” if you like to call it.

If you use Django with DRF (Django Rest Framework) they are very similar indeed.

Django though it’s not a CMS it’s a framework. Strapi is more of a CMS kind of like Wordpress :slight_smile:

I do see the similarities but if you work with both they are way different.

Strapi takes shorter time to setup and work with, as a frontend developer, while Django can crunch more numbers etc, due to been python.

Thanks for the input! Now obviously JavaScript and Python are different, but I want to compare Strapi vs Django as a general framework instead. Django also has front end capabilities but I just want to compare their backend capabilities.

Based on my experience with Strapi and Django, Strapi has a much more customizable “admin site” than Django, and Django allows you to customize your models more than Strapi. Setting up models in Django is done in code where in Strapi we do it directly in the UI. So I definitely see the content management abilities and model customization between both frameworks being different. Other than that, they feel quite similar to me when it comes to the most important features. They both have user authentication out of the box, and we can create custom controllers, services, & middlewares to query the data however we want and create whatever kind of custom logic we need for each route.

I didn’t mean to try and compare Strapi specifically to Django, I was just using Django as an example trying to get the point across that Strapi feels like a backend web framework. To me, it feels like a backend web framework with the added benefit of being a CMS. Or I could flip that and say it’s a CMS with an added benefit of being a backend web framework.

I don’t know of other CMSs or backend web frameworks that combine both like this. Is this what makes Strapi special?

Also as a side question, I’m using Strapi as the data access layer, and a flask server as my business logic layer (with React on the front end.) Does this architecture sound reasonable?

That’s a bit incorrect.
BTW I teach new people how to use django for 4 years so I’m fully aware of some of the things you are saying.

Models in django are thr same in strapi, you can cause strapi to create it in the ui or define thr models.

Django comes out as a framework because of its frontend and jinja capabilities.

Strapi is a headless cms because you can create the backend with the ui if you so choose, just like WordPress.

Not saying you are wrong, and yes similarities but django is a framework strapi is more of a cms :blush:

To add to your flask bit, don’t see why you need to you can use react to talk directly to strapi instead of run a flask server as a middle man.
BTW flask is also awesome but better for APIs or micro controllers.

1 Like

Got it, thank you for the insights. I’ll keep this in mind in case I ever feel I need a more powerful backend web framework. I was hoping Strapi could take over almost all of the responsibilities Django offers, but it sounds like that may not be the case.

And I’m adding Flask as a middleman so that it can handle all the business logic, and Strapi is only concerned with the data access layer. I’m hoping separating the concerns will make adding more features simpler. I’ll be adding a lot of business logic and I’d rather not mix it in with Strapi if I don’t need to.

Well you can say it can if you are using react as your frontend. Then you can use react and strapi.
What you are doing or what it seems to me like is you are using flask to do the logic that strapi can do anyways.
Because you can customize the controllers the routes the models. Just like you can do in django and in flask.

So if it’s that your not to familiar with strapi then of course that makes sense, but how do you get more familiar with Strapi. you customize it :slight_smile:

Ah ok, well great to hear! That is reassuring to know Strapi can replace Django as a backend, which was exactly what I was hoping for :).

I originally had all of my business logic in the controllers of Strapi actually, but I decided to extract that logic out into a flask app to have better separation of concerns for code maintainability purposes. So from Strapi I just have small controllers now that simply return data queried from the database, and then in Python I can process that data however I want and send that data to the front end. I much prefer Python over JavaScript when it comes to coding algorithms (and possibly data analysis in the future) which is another reason I decided to split it up like that.

Technically yes Strapi is both a backend framework and a headless CMS (though my marketing and product teams would largely disagree with that statement).

What makes a CMS a CMS (headless or not) is the level of abstraction applied to the backend framework and how content creation/management is supported for the user. There is different approaches for things like internationalization (i18n) and concepts like components and dynamic zones.

In a normal backend framework (and functionally even at our database layer) these are simply relations but within Strapi they are treated differently than “just a relation” as there is a layer of abstraction applied.

2 Likes

+1 @DMehaffy

We define ourselves as a CMS because we are one, but also to not disappoint the current and future users. The product is going into a direction to become an, even more, better CMS, not backend framework. Our roadmap includes Reviews & Publication workflows, Content History, Audit Logs, Notification Center, a better Draft & Publish system, managing content per communication channels/devices, etc. We want to help you to write better, faster & stronger content.

Technically, you can remove the administration panel, and do everything by code; we will always try to make things optionable for everyone, but we might have to make choices that would benefit most the CMS users than the backend users.