I have a fairly complex Django project which currently serves a website using the internal Django templates.
I’m looking to separate the front and back ends by converting the Django backend into a REST API with Django Rest Framework and using a Vue frontend to render it all.
However, my client is looking to have a lot more control over the content of some of the pages - number of columns, layout, content, images etc.
I like the look of Strapi but I’m not sure that it fits this use case. The Django backend is the source of a lot of the frontend stuff like the events that people can book on to and the process by which they actually make a booking - but does it make sense to use Strapi for the page content in this way? Is something like Wagtail a better option for me?
Welcome to the Community @bodger
Wagtail might work.
The difference between django and strapi is quite simply.
Django is a full stack framework, Batteries included with a front end.
If you separate it using DRF then yes Strapi can do the exact same thing.
Just as much as django has hoops do things strapi will have the same thing.
Can you do the same yes, it’s just Javascript vs Python theoretically.
Wagtail is also quite a good option, though you might feel that DRF / Wagtail with django might be heavier then what strapi is in what you have on it.
I personally done multiple strapi projects that I converted from Django. It’s the same idea just different ways of writing and doing.
Thanks for the reply. I’m not looking to replace Django with Strapi. I was thinking that Strapi could be used for the content editors to define what’s actually on the pages etc. and that Django (through DRF) could provide the more complex functionality of things like events and bookings to and from the database.
It does but it would it not be what you want.
Django controls 1 database and strapi controls it’s own.
Then you need to use REST to communicate with them both which is then pointless.
Think of it like haveing Wordpress installed in two separate places to try control the same data.
Vue on the front does not care where it consumes the data, so yeah you could have had both. But it’s twice the amount of consumption and two times the admin panels to control things.
Ah, that helps me understand a bit more, thanks. So there’s no way in Strapi of saying “get the page content from Strapi but insert some data that has been fetched from the Django API”?
I can see that that sounds a bit mad but I like the idea of using Strapi for content and Django for data.
So maybe the Wagtail route is my best (only) option here.
You can but it’s alot of mess around it.
You would need to fetch data from two sources then select what to build from each source etc.
So it’s possible indeed.
Hi @Eventyret - this thread was from a while ago but I’m revisiting it as I think it might make sense for me to go this way but I just want to check with you as you seem pretty clued up on Strapi.
So, from what I can see, Strapi is a headless CMS and what that means is that it can provide JSON data which describes the intended content of a page or part of a page. Then, on top of that, someone would code a frontend which consumes that data and displays it however it sees fit.
My Django site would also provide data - via Django Rest Framework, from the django database - but this data would be things like “a list of events, their dates, locations etc.” and it would also be able to receive things like HTTP POSTs which would allow users to book on to those events.
So, what I’m thinking is that I would use the Strapi API and database to provide the data for the content of some of the pages (the home page, the About page etc.) and my Django API to provide the data for the content of other pages (the Events page, the page of a specific event etc.) and to allow the booking process to work. The Django API would also be responsible for things like authentication.
If I do it this way, then yes, there are two different databases and two different ways to dictate what the website shows - but we would have “content managers” who would use the Strapi dashboard to edit the pages they have control of and “event managers” who would use the Django admin dashboard to create the events etc. We definitely still need the Django side of things because there’s a lot more going on behind the scenes with these events than just where and when they are - we have a whole management process for assigning these events to teachers along with other things like invoicing.
So I think it does make sense to fetch data from two sources in this case. I think (!). Do you agree or am I going down the wrong route here? The way I see it is that I’m taking some of the content of the front end of the website out of the Django code and putting it into Strapi so that some of our management staff can edit it instead of having to ask the developers to change it.
I really appreciate your thoughts on this - I’m the only tech guy where I work so it’s hard for me to get useful advice when it comes to using these kinds of tools! So thanks in advance!
Hi sorry for a late reply I have been away on Parental Leave
So you can do that, though all I was saying is you are using two separate CMS’es for the same purpose so that means twice the amount of logins etc.
Though you could possible use an API key in Strapi to protect some of the data and have django fetch that from strapi.
So content editors would use strapi, django would authenticate and render the data for you.
Thanks for the info - I don’t think we have a problem with the content editors dictating the contents of some of the pages (and having to log in to Strapi for that) and the people that create events etc. logging and managing that data through Django.
Then the frontend just gathers the various bits of data it needs from Django and Strapi in order to fully create the website.
