Podio as CMS for a JAMstack website
In context of a collaboration tool evaluation for a client some years ago, I had first contact with Podio. And the most amazing aspect of Podio is the flexible data model. Together with all the other features, that makes Podio the perfect tool for internal data management.
Using Contentful in some web projects and trying out the built.io content stack, the concept felt quite familiar and I decided to have a second look at Podio - now as CMS for websites.
Pro:
- The data model is really flexible and not that far away from Contentful or build.io.
- If Podio is already used for e.g. internal data management, intranet communication or similar, it would make sense to use Podio for the web as well. So internal content and data can be shared and web content can use already existing assets in an already used system.
- The API could be a little slimmer, but is easy to use and javascript client libraries are existing.
Cons:
- The API is strctly rate limited and not made for direct and high performant data access. But with a JAMstack approach, that is not that important.
- The data model has restrictions in flexibility, e.g. not having a explicit video data type and having only one generic file attribute.
- Managing multi-language content has to be done by custom attributes - there is no core concept.
- Realising publishing workflows is possible, but there is not ready-to-use core concept.
- As Podio is not that often in scope as CMS, the existing integrations are sometimes missing. Using Podio as CMS would mean to create a bunch of GulpJS tasks or a GatsbyJS source module.
As an overall result we decided to go for Podio for smaller corporate websites and use a GulpJS based JAMstack.
Update: While we already wrote most of the GulpJS tasks with a sexy json mapping and reduction component, we found GatsbyJS, which might replace our GulpJS ideas. So maybe we have to throw the GulpJS tasks away and switch to a GatsbyJS source component.