Support the ongoing development of Laravel.io →
Architecture
Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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)

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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?

Last updated 2 years ago.
0

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).

Last updated 2 years ago.
0

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?

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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?

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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

They kind of do exactly as you want.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

Check this out: http://deployd.com

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

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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-loosely-coupled-monoliths-read-only-apis.html

Last updated 2 years ago.
0

dadaxr said:

Another smart read is : http://www.phillipadsmith.com/2011/07/the-post-post-cms-cms-loosely-coupled-monoliths-read-only-apis.html

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.

Last updated 2 years ago.
0

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

Last updated 2 years ago.
0

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...

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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?

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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!

Last updated 9 years ago.
0

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.

0

Sign in to participate in this thread!

Eventy

Your banner here too?

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.