Skip to content

Instantly share code, notes, and snippets.

@designermonkey
Last active December 16, 2015 04:58
Show Gist options
  • Save designermonkey/5380725 to your computer and use it in GitHub Desktop.
Save designermonkey/5380725 to your computer and use it in GitHub Desktop.
Draft proposal for the Symphony Next project.
  • Draft Number: 1
  • Date: 2013-04-14
  • Author: John Porter @designermonkey

Symphony Next

This is all still a little new to me, so forgive me if this sounds naive, or you all have already thought about this and it's obvious, but I've been thinking about how we actually build Next. (I like this as a project codename).

Proposing the Application

I want us to try and separate the areas of interest in the application logic, so we really take advantage of the IoC pattern, and apply this pattern throughout our application. While we all know about unit testing on each component, and the benefits this delivers, we should also apply this thinking to groups of components.

I am thinking that we will have different groups, or layers in our application that should ideally remain completely separate from the other layers:

Platform Layer

We will of course have the platform layer, which hopefully will be Laravel (I think we're all kind of sold on this one), which has it's own testing and is done by those who develop it. I don't need to say much more here, other than we will be restructuring the paths of the app to more follow how we currently structure Symphony. I don't mean the internals, but have workspace instead of public etc.

Symphony API Layer

The underlying logic of Symphony is a separate application in itself, maintaining our principles in data abstraction and provision, although we need to expand on the latter to keep up to date with trends in the industry.

I won't go into too much detail here about specifics like datasources, events, sections etc, but these need redefining in the new context.

Schema Based Data Provision

This expansion mentioned previously, would be in the form of providing schema based XML, schema based JSON, serialised PHP, and PHP Objects (like Entry, Field, as we currently have). Schemas are standards, and we advocate standards, so we should set all of our data against a schema. When it comes to Sections and Fields, a schema should be generated for each section.

Schemas should be versioned, so any changes to section schemas should increment a version number, and by proxy increment an API version number.

Schema resources include:

REST Architecture

Symphony as a new App should be a fully REST API. It's as simple as that.

Symphony should utilise all available REST verbs, and provide fallbacks for using unavailable verbs through web-forms; like passing PUT through a web-form's POST method (until web-forms are fixed, proposed here) using parameters. A fallback would be the POST verb catching a method parameter specifying PUT/DELETE, and passing the data to that method instead.

REST resources include:

Requester Agnostic API

The API should not care about the application making requests. We currently state that we make no assumptions to how a developer/designer builds thier front-end. We should apply this tenet to the application as a whole and allow any application to be able to make requests of our API, as long as they use the correct schema for requests.

Data Storage

We need to re-address our database interaction. This is a sore spot after all of the work in efficiency of the SQL in Symphony over the years, but all that work will leave us with awesome knowledge of our data structure. We need to make use of the ORM in Laravel. This needs more thinking about and defining (as I havent read up on it yet). If anyone would like to propose ideas here, please do.

Human Interface

We will provide the best Human Interface for the API, in the form of the Symphony Admin. This will allow the core team to concentrate on improving the API, and provide documentation to the UX/UI team, who inturn will improve the Human Interface. Keeping a strict separation of interests throughout the applciation will allow for other template languages to build a Human, or Machine Interface. As a working group, we should have no part in any other interface, instead concentrating on maintaining and documenting the API and

Application Process Outline

A quick outline of the application process, to be expanded upon.

A User visits the site URL, which triggers a specific route to fire up the designer/developer built Human Interface (front-end), which in turn runs and queries the Symphony API using the defined endpoints.

A User visits the site URL appended with the admin URL (specified in a config), which triggers a specific route to fire up the core Human Interface (admin), which in turn runs and queries the Symphony API using the defined endpoints.

A User, or Computer visits the site URL appended with /api, which triggers a specific route to run and query the Symphony API using defined endpoints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment