What’s the purpose behind this topic? Simple, it’s to talk about all web based technologies, it doesn’t have to be back end, it doesn’t have to be front end, it can even be configuration or architecture. So… I’ll start…
I’d like to start by saying that I’ve not reinvented the wheel here, all I’ve done is live by my moto.
This is a pretty damn good wheel, but it could do with some oil, a nice paint job an’ some racing tyres.
So that’s essentially what I’m trying to achieve. I’ve had a look through various design patterns, features, concepts and implementations that spawn across the entire stack, on various tech stacks and I thought know what, screw it, I’m bored.
Says the guy who has a full time career, is studying part time and working as a freelance developer when possible, on top of doing a bunch of other stuff too.
My end goal is to define a design that can be transferred from project to project, I’ve begun developing a mock up of this design in PHP, I wouldn’t quite call it a framework yet as it’s so incomplete. Plus as it’s a design, it’s meant to be used to help define the architecture of the given project.
Okay, so I’m trying to define an implementation/system design that I can transfer from one project to another, without taking into account the technologies in use, so far my design consists of & takes into account the following:
- MV-Hybrid (MVC/MVP)
- Micro Services
- Dual Routing
- User Roles
- Load Balancing
Okay so the idea(s) behind my full stack design essentially merge a bunch of other ideas together, there’s not much to it more than that. I decided to go with an MVC/MVP like design because for the sake of the fact that it works, it’s easy to understand and considering it’s so popular, other developers can make sense of it without a large or even moderate learning curve.
I say it’s partially MVP because I personally believe that the data should go through the controller layer both ways. But that’s just a personal preference, if you want to go MVC and have your model send data back to the view, I guess that’s no problem either, and you’re still essentially following the outline(s) of the design.
The idea is to develop the back end as a RESTful API, allowing you to separate the front end as a completely different application. This way, you can have a variety of front end applications that can all interact with the same back end, using the same logic, to me this makes much more sense, and it means that evolution should be easier. I mean you don’t have to touch the back end if you want to make a hybrid web app, or a native app, it’s all there, all you need to do is possibly re-write how the data gets rendered (aka the front end), or in theory that’s about it.
Plus when you want to implement the next version of your API, it makes life a hell of a lot easier if you decide to migrate from one back end to another. I mean if you wanted to migrate to a totally different tech stack, it should be a lot easier compared to a lot of web apps that use server side rendering, it’s modular as hell! Obviously the same applies to the front end too, they don’t affect one another provided there are no major bugs on one end.
Here’s an image to help explain how this design works… So far.
Personally, I’d implement this design through using the LAMP stack to start with, then in future, if necessary, migrate to the MEAN stack, or the J2EE stack or whatever. Obviously it would be a matter of the right tool for the job, I only say I’d start with the LAMP stack because practically every hosting company has a deal that will support the LAMP stack without any config/fiddling around, and I know that there are some packages that won’t support x,y or z without an additional charge, etc.
So you can see, I’ve got two routers, why?
I mean why not? You can have a nice and pretty URL for your front end and then have some horrible/foul looking URL for your back end (if necessary), it’s really that simple.
Plus having dual routing means that you have the option of doing 90% of the work on the back end and then 10% on the front end, or vice versa, it’s no longer a matter of chose client side routing or server side.
I decided to have a security layer interact with the back end router because even if a client is trying to be a wizard and navigate to stuff they don’t have access to, worst case scenario, the back end router will just tell the client to get lost, and the client can’t retrieve data through that end point (401).
Another thing I’d like to talk about is what would you rather implement, and why?
- Web Sockets
- Web Sockets (Comet fallback)