- Draft Number: 1
- Date: 2013-04-14
- Author: John Porter @designermonkey
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).
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:
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.
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.
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:
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:
- Wikipedia: Representional State Transfer
- Haters gonna HATEOAS
- How I explained REST to my Wife (I can't believe this article was removed from the original source!)
- Other Links
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.
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.
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
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.