Awesome idea! Would live to see this idea become reality.

Thinking of using something like http://phpcr.github.io ?

a couple of guys are doing a great job on https://github.com/dingo/api

as far as SEO goes, people can query the API with JS and if a bot swings but they can query the same API with something like PHP (based on request headers for example)

On the bit about a frontend learning curve:

I think it would be relatively simple to have a library that automatically takes API endpoints and parses them into variables, ready for Blade. Alternatively, something more automagical could use a different templating system, and automatically pull in things based on what's in the templates; I could imagine a fully view-based frontend working this way, doing nothing fancier than:

@with API("/posts/$id?embed=comments") as $post
<article>
<h1>{{ $post->title }}</h1>
{{ $post->contents }}
<div class="comments">
    @foreach $post->comments as $comment
        <p> {{ $comment->body }} </p>
    @endforeach
</div>
</article>
@endwith

Of course, if the team decided to use a different frontend - or use multiple frontend packages - they'd be completely free to mix and match!

Also, the dingo/api package has an "internal requests" feature which would be handy for things that prefer to run on the same server as the backend. I'm not completely sure how this would work together, but it's a concept that should be carried forward. It has really cool things like continuing exceptions instead of rendering them as JSON/HTTP.

Thanks for the replies guys. Yeah perhaps focusing on a wrapper that makes it simple to interact with the API using an extension of Blade would be very beneficial as most developers would be deploying everything onto the one box, as opposed to having the API (and DB) on one box, the admin dashboard on another and the client's site on an a third box. However, I think it would be important to design & code the admin dashboard as if it would never be on the same box as the API, purely so that it can be easily swapped out with any replacement you want.

What do you guys think?

There must be a way so we can transparently adapt these with a single change of configuration. Maybe some sort of driver for laravel, which allows client packages to do, what, Whatever::get('/users/$id') which defaults to a cURL request to the API (as you expect it to), but, if configured, transparently invokes a route or something. This gives clients freedom, since they can start out being hosted on the same box (or even the same laravel install) and then later migrate it to a different box/server/whatever with only a flip of a config switch.

This gives a significant scalability boost, especially if the backend were made to scale nicely as well. And it would genuinely be more than a mere CMS, since we can have any number of client working with the documents in any sort of way on any machine. It'd also carry its own ecosystem around.

I think right now the difficult problem is defining a document schema so users can customize the CMS to their needs, and to make this document schema available to the API clients (e.g. if a blog post document has a Location property, how we tell this to frontends so they can accommodate for it).

Yes, there's lots of possibilities. If there was an PHP API wrapper and the Admin Dashboard was written with it, it'd certainly make development easier as everything would be in PHP and it'd force the development of the API and the PHP API wrapper. What's your take?

rizqidjamaluddin said: I think right now the difficult problem is defining a document schema so users can customize the CMS to their needs, and to make this document schema available to the API clients (e.g. if a blog post document has a Location property, how we tell this to frontends so they can accommodate for it).

I plan to map this stuff out using http://apiary.io/ which will certainly help. I've already been thinking about things like you mention (location information related to a blog post for example). Is this something the API platform should include out of the box or simply allow developers to easily extend the API (and conform to API consumer-expectations)? This seems like an extension to me, but these kind of things could be rolled into the CMS over time. I mean, we couldn't expect to have all possible field types out of the box from day one.

I think the normal approach works nicely; built-in, ready-to-use templates for common types of document properties ('location', 'time', 'datetime', etc) for third parties to use quickly, and allow them all to be extendible. In regards to actually storing the document structure, would the Doctrine/Symfony route of adding metadata in files regarding documents be better, or have a sort of abstracted, dynamic document structure stored somewhere?

rizqidjamaluddin said:

I think the normal approach works nicely; built-in, ready-to-use templates for common types of document properties ('location', 'time', 'datetime', etc) for third parties to use quickly, and allow them all to be extendible. In regards to actually storing the document structure, would the Doctrine/Symfony route of adding metadata in files regarding documents be better, or have a sort of abstracted, dynamic document structure stored somewhere?

Yeah, that's a tricky one as the API could have to return quite long JSON responses in certain scenarios, which could mean extensive & expensive DB queries via Eloquent. Though most CMSs do this already, the majority store serialised JSON in the DB, much like a pseudo-document store.

Take a look at https://prismic.io/

They kind of do exactly as you want.

baasjef said:

Take a look at https://prismic.io/

They kind of do exactly as you want.

Funny, myself and Rizqi mentioned them in IRC the other day. Yeah, they're doing what I'm talking about, however, they're a hosted solution, which is not always ideal. Sure, we could borrow a lot of neat ideas from them etc. but I'm more interested in created an open-source, self-hosted solution.

Love the idea. I like prismic.io's idea very much too and it definitely can be used as starting point.

Not sure how to watch treads here, but I'm going to try to contribute if that idea goes into codding.

So what features would you guys be looking for? I'm not sure how many of you are familiar with Expression Engine or Craft CMS, but they offer quite complex content relationship possibilities and grid/matrix capabilities.

mikhailkozlov said:

Love the idea. I like prismic.io's idea very much too and it definitely can be used as starting point.

Not sure how to watch treads here, but I'm going to try to contribute if that idea goes into codding.

No unfortunately you cannot watch threads or be notified of replies by email. I believe Shawn, Nick & Co. are working on it though.

niallobrien said:

So what features would you guys be looking for? I'm not sure how many of you are familiar with Expression Engine or Craft CMS, but they offer quite complex content relationship possibilities and grid/matrix capabilities.

I'm sure people would love to have all the features they can have, but I personally like KISS or Wordpress like approach.

Looking at prismic right now to get an idea of what it offers. Going to use it on a small project I have and I will report with findings.

Wordpress approach? You're kidding, right? Please take a look at the features offered by Expression Engine or Craft CMS and compare them to Wordpress. No contest.

niallobrien said:

Wordpress approach? You're kidding, right? Please take a look at the features offered by Expression Engine or Craft CMS and compare them to Wordpress. No contest.

This is why i've started with "people would love to have all the features they can have".

Building new CMS is hard, it becomes real challenge if you over stuff it with features from the get go. I like agile approach to thing and alpha/beta version should have minimal set of features imho.

Looking at prismic.io right now and it looks like it covers all use cases I have. Not sure if they have search yet, but I'm sure I can work it out even if they do not have it.

Yeah, I agree. I think the key would be to offer a core set of functionality but allow devs to also easily extend the API. A plugin might consist of two parts, the code necessary to hook into the API server and add its functionality to the response but also the front-end required for the admin dashboard.

I also believe this is the way to go. There are many CMS's out there based on laravel, but none of these seems to gain a large audience. From a developper point of view, I don't need a too much opiniated CMS, still I'd love a package that leverage the task of content management/edition, and who would take care of permission and validation in a very flexible way. In that regard, I think that Fronzenode/Administrator, while it's not an API, is a good example of what such a package could be.

I'll try get a start on defining a typical document structure and API response before touching any code. Obviously I know my needs are probably much greater then most; a simple blog will not do what I need but will probably meet the needs of many people out there. And so long as the platform is extensible, then there should be no problems. Of course, dealing with API auth etc. could be a potential pain, especially if you want to build a simple e-commerce solution.

About handling the data, the tricky part is that you have to think about a large number of user scenarios, with potentially complex relationships.. I've started the process since last month of refactoring my company CMS using the exact approach described in this thread, and there are many questions I'm facing, it's definitely not an easy task. I would love for example to have a repository based system but at the same time eloquent has so much awesomeness that I'm really tempted to tightly couple the system to it.

Check this out: http://deployd.com

It is like prismic.io but open source... The project seems on hold at the moment, though.

esclapes said:

Check this out: http://deployd.com

It is like prismic.io but open source... The project seems on hold at the moment, though.

That's more going into http://nobackend.org/ territory like Firebase and http://hood.ie etc.

Poked around prismic.io and it seem to be fine for basic website content mamagment. CMS concept is easy to grasp i think. Files and images are pushed to AWS for fast access. UI is simple and probably most content writers will be able to get a grip on it fast. It has "post type" builder out of the box. It is not super flexible, but usable. Not 100% sure how whole release cycle will fit into workflow, but it is nice idea for sure. UI has file and image manager build in (huge plus in my book).

API is very basic and I think simplicity is what makes it great.

There is only one downside for me is that files go to AWS and you have no control over who and how can access them. I would love to see file API, so you can control who get's to see files.

In over news October CMS (http://octobercms.com/) is out in case you missed it.

Hi there :)

Just to add another reference to API-Centric CMS : https://www.contentful.com/

Same as Prismic.io but with an read/write API ( prismic api can only "read" content, the "write" part is handled by the backend writing room, so you can't plug "front end user" contributions )

Another smart read is : http://www.phillipadsmith.com/2011/07/the-post-post-cms-cms-lo...

dadaxr said:

Another smart read is : http://www.phillipadsmith.com/2011/07/the-post-post-cms-cms-lo...

Thanks this was really insightful !

I really think such a laravel package would greatly benefit to the community. As I see it would be a read/write API based on Dingo/API (which I played around a little with and it's really great) , and a toolset that would let developper plug-in custom content & business objects , while leveraging the whole CRUD + Validation + Permission process. I started to code a little in that direction, but there is still a lot to be done.

Really interesting stuff guys, thanks for the links! :)

Niall & I have chatted about this already, but a friend and I have started writing CraftCMS plugins at http://ninetwelve.co/ and our first plugin is going to be an API plugin... based exactly on the needs we're discussing here. I'll try to ping back here when we get some progress...

I really think you should take a look at http://phpcr.github.io. I believe work has already began to implement this interface around https://prismic.io as well.

Dunno why I didn't mention it before, but a server-side wrapper could make it very easy to make server-side templates, much like Blade. Also, perhaps Flysystem might be able to help in this scenario? Thoughts?

Niall, any progress on this? I am very interested in a laravel component to add to a number of web app and mobile app projects. Would be happy to help code it up.

Hey niallobrien I am very interested in this thread. Did you ever get it off the ground, or are you still defining the concept? I would love to contribute to a project like this!

Hey guys, just a quick update: hoping to get this project off the ground soon, but will more than likely employ a fullstack JS approach, this would open the possibility of using websockets etc.