Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
This question should serve as a listing of all the different backend-agnostic admin interfaces. Update the community wiki answer below to add more.
This is a community wiki answer. You should edit me with your improvements. Alphabetically sorted.
Implementations
AdminJS is a database table like GUI with CRUD abilities
NOTE: No longer maintained.
(source: webresourcesdepot.com)
Create.js is an inline editing GUI for editing content and managing collections, it provides a widget interface and can be extended to have WYSIWYG editors placed ontop of it
(source: bergie.iki.fi)
HydraConsole is a generic API console for Hydra-powered Web APIs.
Lumber Lumber uses your SQL or MongoDB database to generates a modern Admin Interface application that is completely backend agnostic and highly flexible.
ng-admin: Add an AngularJS admin GUI to any RESTful API
Web Write's InlineGUI is an inline editing GUI with CRUD and site management abilities
Specs/Frameworks
Create.js Backend Integration Guide - REST API spec for CRUD actions
VIE - server-agnostic JavaScript data layer built on the W3C RDFa and JSON-LD specs and used in Create.js
Hydra - a lightweight vocabulary to create hypermedia-driven Web APIs. By specifying a number of concepts commonly used in Web APIs it enables the creation of generic API clients.
Web Write Spec - REST API spec for CRUD actions and collection listings
Neutron Protocol - XML and WebDAV protocol for content editing
The Atom Publishing Protocol - XML and WebDAV protocol for content editing
MetaWeblog API - XML-RPC API for blog-oriented content editing
Data.js - data representation framework for Javascript
Twingle - XUL application and protocol for cross-system content editing (discontinued)
Articles
Moving DocPad Forward, the rise of backend-agnostic GUIs
Decoupling Content Management
VIE 2.0 is starting to emerge
Using RDFa to make web pages editable
Neutrol Protocol - separating UI from the CMS
ng-admin: Add an AngularJS admin GUI to any RESTful API
There is also https://github.com/punkave/jquery-rest-admin
In this context http://jsonapi.org could also start playing a role.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I am trying to understand their difference.
From my understanding, Apollo is an implementation of GraphQL, and Gatsby is a framework that uses Apollo to build severside-rendered apps. Is that interpretation correct?
Would appreciate any input!
Apollo (apollo-client) is a highly customizable graphql client with normalizing cache.
Gatsby is a node.js based static content generator. Resuls with a kind of [severside rendered] react app that can be 'run' from any (cheap) server supporting static content (static html, js, images) - even without any dynamic content support (f.e. php). Pages are prerendered as html (good for SEO) and transition between them is optimized (preloading).
Gatsby and graphql - it manages internally content in redux but provides graphql api data source consumed (in pages/templates) by own/internal client/lib to create static [fast] pages. This is compile time only 'server+client'. De facto not server and not client (not apollo), more like a set of helpers (customizable compiling system) using graphql querying format to describe templates data requirements, data processing etc.
You can use apollo-client [react] components/hooks in gatsby page templates for run-time data fetching [from static/generated pages]. You can use it in gatsby's node.js compiling environment for data fetching (instead of source plugins).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I want to start a project but I am unable to select a technology. I basically work in JavaScript. So, develop a project with JavaScript both in front end and back end will be good for me. But I need a suggestion regarding a headless cms called Strapi. Why should I use it with React? What is the advantage and disadvantage of using strapi with react. Because Strapi is still fixing many bugs they had with their alpha version. So, I need a suggestion for this case.
You are not required to use React in your client application while creating a project with Strapi. The whole concept of is that Strapi is front-end agnostic which means that you can use it with your preferred framework or library.
The administration panel which is provided with your project is built with React, however it is completely different than your client application.
You already said, Strapi is a Headless CMS, which is defined as:
A headless CMS is a back-end only content management system (CMS)
built from the ground up as a content repository that makes content
accessible via a RESTful API for display on any device.
source
This explains why it is NOT A MUST to use a React Library, #scoupette pointed out. It does not work with REACT itself, it just sends you a data as a response, when you query something or gaining access to somewhere.
Strapi is meant to stay as a backend. Be responsible for all hard work like authentication, content type management and flexibility. When you create a content type in Strapi, you are not limited by creating only Posts or Pages, as it would be on a Wordpress default CMS configuration.
When you start developing in Strapi, generally is enough to control the backend and whole system you have created only by sending and receiving some JSON data between the listening server on default :1337 port. I do it with Postman. Whenever you decide to build a frontend, you start "rendering" the JSON responses got from Strapi. They might be displayed on your web app using: React, Gatsby, Angular, Next.js and many more. You can find their "Blog" demos with those frontend frameworks on the website.
Now lets have a look at the second part of the question:
What is the advantage and disadvantage of using strapi with react
Let's reassemble the question: Pros and Cons of using React with a Headless CMS. To know that you have to compare it with other opportunities we have, but that might get us out of the topic. Instead you might like to refer more experienced users of the frameworks in The Best JS Frameworks for Front End.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have zero web programming experience but has been in IT industry for a while, mainly as a CRM technical consultant. I'm familiar with VBScript and Javascript, not in a Web context but as general scripting tools. I'm good at designing business processes, database models and using DB queries. I have some basic understanding of GAE and Python by doing the tutorials by Google. I used to write some tools with C# and VB6 a long time ago.
So I've decided to build my first website on Google AppEngine, and I'm lost in so many choices and new skills to learn.
What I'm planning to build is a simple website where users can post short messages and vote upon them. Which requires a simple but dynamic front page, login/cookie handling, Reddit like post voting/aging and some data storage.
Maybe the first question is which framework should I use? I heard Flask is good for beginner to learn web programming and webapp2 is easy to start since it's integrated to GAE by default. I've looked at Django as well, it looks very powerful, but I couldn't decide.
Since my idea is largely based on a concise but dynamic front page, I guess something AJAX is a must. But I have no clue on where to start. All those Ajax, Jquery, ProtoRPC are so confusing. Which technologies should I use and where can I find good tutorials?
I am also looking for suggestions on potential challenges and anything I should learn to achieve my goal. Thanks!
Since your project is inspired by reddit, the web development course with Steve Huffman (the technical founder of reddit) will be extremely helpful for you.
https://www.udacity.com/course/cs253 - it's free if you just watch the courseware. He even explains their aging algorithms in the end.
This course covers the back-end side of building a python applicaiton with the default webapp2 framework on appengine. He doesn't cover the front-end besides the basics (HTML forms and tables, stuff like this).
Now, Jquery is a Javascript library which is used by about all of the dynamic websites. It is a convenient way to work with the DOM on the fly. Everything you can do with jQuery, you can do with plain javascript, it's just that jQuery is infinitely easier to work with.
This library is used on the front-end, and it doesn't matter what backend you choose. It is extremely simple and powerful and you can learn the basics at the free codeschool course try.jquery.com.
Basically, if you want something to happen on the page dynamically (the arrow becomes red once the user clicked on it), you use jQuery.
AJAX is asynchronous communication with the server, it can be done by plain javascript but jQuery provides a very convenient wrapper for doing it. Usecase: the user clicked on the arrow, you painted it in red with jQuery, you incremented the votes counter (again with jQuery), and now you need to send the upvote to the server without reloading the page. For this you perform jQuery.ajax() call, and pass the user data as a param.
So to wrap it up: you need to write javascript to make a dynamic page and jQuery is the most common library that helps you with this. You need AJAX to get and post data to the server without page refreshes, this is implemented in jQuery. You can use jQuery with any back-end framework that you choose. Start with the simple jQuery tutorial, then read about $.ajax call and it will be clear for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Single Page Apps are well known. But PageAx seems to be less well known. I stumbled across it by accident in learning MVC and it has worked quite well for me so far.
(Note: I am aware that this is a topic which may be regarded as "not answerable" and "should be closed" yet I feel this is an important topic which has not yet been covered. Note that this is Single Page Apps vs. PageAx (not Ajax). I am looking for benefits/disadvantage type discussion. I am making up the name "PageAx" as I have not found a better term for it.)
SPA - communication with controller via Ajax and returning Json.
PageAx - communication with controller via Ajax and returning partial views which replace divisions.
Here are the benefits of PageAx as I see it, over SPA's:
Little to no JavaScript on the client.
I find Partial Views very easy to write on the server side.
Benefits of SPA over PageAx:
I can't think of any.
Disadvantages of PageAx over SPA:
Slightly larger payload (but I doubt it would be discernible by end user.)
I can't think of any other.
Disadvantages of SPA over PageAx:
Seems like the amount of JavaScript and required libraries present a fairly large learning curve (i.e., more so than MVC.)
So to re-iterate the question, are there any advantages to SPA over PageAx? The basic reason for the question is that I am starting yet another web project and need to decide which way to take it.
This depends on complexity of your application.
Returning JSON is beneficial because hey—that means you have a full-fledged API that you can reuse in a mobile app or a desktop client. Even if you later decide to completely re-do your frontend, you will already have a ready-to-use backend to code against.
Also, if your webapp is highly dynamic and interactive, replacing partial views may not be enough. You may want to have finer control over transitions (e.g. animating them). For example, see Medium-Style Page Transitions: you can't do something like this with partial AJAX views.
On the other hand, if this flexibility doesn't buy you anything, rendering partial views on the server may work very well for you. Here's David from 37signals blogging about it. He calls this approach SJR (Server-generated JavaScript Responses):
This doesn’t mean that there’s no place for generating JSON on the server and views on the client. We do that for the minority case where UI fidelity is very high and lots of view state is maintained, like our calendar. When that route is called for, we use Sam’s excellent Eco template system (think ERB for CoffeeScript).
If your web application is all high-fidelity UI, it’s completely legit to go this route all the way. You’re paying a high price to buy yourself something fancy. No sweat. But if your application is more like Basecamp or Github or the majority of applications on the web that are proud of their document-based roots, then you really should embrace SJR with open arms.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'd like to build a highly scalable, highly transactional web platform to run multiple websites. Product information will come from an external PIM, search will be provided by an external service and it will also need to integrate with an ERP system for order processing.
The two functional areas I have left to decide upon are the web CMS and the commerce framework. I have been looking at Sitecore, EpiServer, Magento and MS Commerce.
Whilst Episerver and Sitecore have great WCMS capabilities, they seem to lack on the commerce side and conversely, whilst Magento and MS commerce have great commerce capability, they lack on the WCMS side.
Does anyone have any experience in integrating a WCMS with a separate Commerce framework?
If so, are there any combinations you would recommend? Eg Sitecore with Magento, EpiServer with MS Commerce etc
Are the benefits of having two separate systems (great in their specific area, decoupled architecture etc) outweighed by the disadvantages (complex interfaces, less out-of-the-box functionality etc)?
Thanks in advance!
EPiServer has a Commerce-packaging since about a year... In it they have integrated with a e-commerce framework from a U.S. company, Mediachase. So to combine EPiServer with a complete commerce product that's probably the smoothest way forward if you decide for EPiServer.
I've attended a course in EPiServer Commerce and it did seem powerful but in my opinion not very pleasant to work with, neither as a developer or a webmaster. I would rather integrate on my own and fetch "commerce" objects into EPiServer pages. Then build shopping cart functionality, order flow and other integration as needed.
The most popular ecommerce package of the moment is Magento and you can do multi-store, multi-currency.
Personally I think it is better to use the full functionality of Magento including the order processing and backend tools for editing the product pages. However, there are many companies that choose not to do this, updating the product data from a backend system (or even an accounts package) and having everything else handled by other packages.
If you want to use a 3rd party CMS with Magento then it is easy if your customers don't have a 'single sign on' - you can relegate the Magento install to /store and customise the CSS to look like your main site.
Alternatively you can go with a Wordpress integration that will let customers add comments to blog posts etc.
Drupal is another package that has been integrated into a Magento build in such a way that customer information is shared between the two packages.
Scaling Magento is not easy but it is designed to scale and there are examples in the wild where lots of servers work together to serve the pages. Master/Slave databases can be used and CDN integration for serving images is out of the box.
I would advise against pulling data through from an offline-database for creating product pages. This is because you cannot tailor pages to have custom options that easily when taking the programmatic approach.
I have previously done a bespoke integration of nopCommerce into an EPiServer site and through the use of an EPiServer Page Provider I was able to create a really tight, clean integration.
I'm currently working with EPiServer Commerce and all this is done for you, though the product URLs don't live within the clean URL structure of the CMS.
For example, a category page might be at
/products/cars/
and the product it's self would be at
/ford-focus.aspx
The aspx URLs are still virtual files (they don't exist on disk) but I'm not a massive fan of the different URL structure.
I understand this is an old post, but if you are looking into sitecore then Insite software have a powerful ecommerce module for it. We are going through a similar CMS/ecom review at the moment.