I’m looking to build a website where all the content will be managed by the client. In the old days I used tinymce for the page body but I’m wondering if this is still the best way of if there are any hidden gems in Wappler which would be better.
@JonL - I’m assuming you’re a strapi.io user? Can you just give me one steer (I’ve read through their website but can’t find the answer to this)…
Does strapi create the database tables or can it be used with an existing database? I am very interested in using this to create the admin area sitting in a folder (eg. /admin) for websites where the front-end is built with Wappler. The last site I built I did the admin area, too, but strapi looks like it will make it even quicker.
Thanks @max_gb. On first glance this looks very similar to strapi. Is the workflow building the site with Wappler and then using Directus to maintain the data via APIs with the Wapper site or does it connect directly to the database?
Here’s an example of how you could set it up. You could use the Directus API as a security level rather than your Wappler project reading and writing directly from your database. This may be a better use case for multi-tenant apps or where you would like a public facing API.
Just checked out Strapi - what a great CMS product! Absolutely love it.
This a great addition to Wappler indeed, for adding a super easy CMS as API!
Doing that with Docker is even easier! GitHub - strapi/strapi-docker: Install and run your first Strapi project using Docker
And with our API Connector you can build indeed a great front end in Wappler to it!
So I will be checking out a good Wappler integration
@George - have you checked out directus.io? Would be very keen to hear your thoughts on both, especially which you think is better when working with Wappler and why.
If @George is considering a Strapi integration in the future I’d stick with Strapi. Works in the same way as Directus does. I know a few others here have used Strapi before too.
Both Strapi and Directus headless CMS solutions are great solutions.
Each have its own strengths and weaknesses.
Strapi is more generic and not database dependent, also it is build in NodeJS giving it great powers. It is great for non technical new users wanting to build CMS API and a front-end/mobile app in Wappler.
Strapi is completely database independent and support most common databases. All data and structure is abstracted as high level content types and field types that are very common, easy to understand and can generate forms and grid easily from them.
Directus is build in PHP and supports only MySQL - it is more a great API and Admin generator on top of that. It is a great fit for existing database users - as it is database first - and more database oriented than Strapi. People have to known more about databases and relational knowledge to use it. But all is greatly integrated in their admin app - so you can easily mutate existing structures and data.
So both Strapi and Directus are actually a perfect fit for Wappler and we will see if we can offer more out of the box integration with them soon.
I hope it’s alright if I ask some rather basic questions about this topic.
Would using these headless CMS systems replace whatever CMS you might develop yourself, using Wappler, or would the idea be to integrate them into your CMS, to provide functionality which would be time-consuming to develop yourself?
In either case, I understand the front-end would still be developed in Wappler, so what exactly is provided by an external, headless, CMS?
I’ve had a quick look at the websites of the two CMS systems mentioned, but I’m not clear about the cases where using these would be an advantage. It seems - from the perspective of someone who clearly doesn’t understand the basics (me) - that integrating a third party database etc. into something you’re developing extra complexity. Eg is it likely to be useful generally or just for a more complicated CMS?
I would be grateful if someone could give me some basic explanation about all this - just to point me in the right direction as it were.