I’m looking for the most efficient path to convert over time my own made php framework for nodejs and I believe that nodejs experts and specific developers who had their years working with apache/php/mysql will be able to give objective answers based on knowledge and experience that won’t be just opinions but solution to a problem.
CONTEXT
I’m working on a project that requires real time functionalities for which node/socket.io appear to be the most efficient solution.
CONSTRAINTS
- I’ve built my own php/mysql OOP framework to manage projects over the years with some very nice functionalities for web content managers and nice functionalities for me to radically simplify specific development (based on my own personal logic obv.) and manage all my projects in just one instance of my framework.
- There is no way I can rewrite all this for node just now.
- I have to keep taking advantages of my framework & back-office tools to work fast while developing my first node apps.
- After this new project is in production, I will start to rewrite for nodejs the functionalities server side & client side; one at a time (keeping my local dev environment & all my project in prod always in sync).
QUESTION
How do I start introducing nodejs to my framework ? so that
-
I won’t spend too much time on it now (except for the node apps I need obviously)
-
I won’t have too many headaches when I start replacing php and the old js to take advantage of node
-
php/mysql & js/mongodb should nicely cohabit on the servers until there is no more php in the framework
my framework logic – abstracted without all the details :
What follows is where I’m at, possible solution I’ve identified & am considering, not additional questions + there may be other ways I’m not aware of yet, hence the post.
Should I better be :
-
For my first node apps : using a proxy like Nginx to have node & apache, mysql & mongodb side by side ? or is it worth investing the time now to have my php engine working with node, using modules for php, sql ? another path ?
-
writing the node apps with mongodb as db server & when necessary exchange values from sql to the app using php ? or is it worth investing right now the time to move from mysql to mongodb the full framework rather than after one tool/functionality at a time ? another path ?
-
converting
- From top to bottom (i.e. starting by replacing the http request handler & have js passing the ball to php for the rest and so on, would I be able to do that ?)
- From bottom to top (i.e. the plugins, the backoffice tools, then templates, then rendering engine…) ?
You may want to consider adding a proxy layer while you are migrating. This provides one URL for your application while specific parts are on separate servers. This is the general approach used by people who use microservices. There are several instances of the services behind one URL space. Something like Zuul or nginx work well there. This lets you hide the fact you are running different servers with very different implementation details from your users.
Next I would start by implementing your first new node apps. Sometimes several smaller apps work better than one large one. It really depends on a few factors. The new architecture can live next to the old architecture just fine.
Do just enough to get moving in the right direction, then evaluate what you have. The more your legacy app migrates to only rendering JSON, the less dependent you are on the style being right.
2
While most folks who ask architecture questions here do so prematurely (they really should be writing some code first to gain a fundamental understanding), I’m going to suggest to you that you should make some basic architectural decisions first. These decisions are technology-agnostic; if you follow them, it’s going to matter less what the actual technologies you choose are.
Architecture is fundamentally a way to organize your application. It provides a skeleton by which you can organize your thoughts, break up large pieces into smaller ones and provide better maintainability by writing your application as a loosely-coupled collection of modules. When you do this, you’ll find that you can focus on writing each module independently, without worrying about what the others are doing or what technologies they will be using.
There are many architectures to choose from, but they all essentially work the same way: they give each module a role, and then establish interfaces between your modules. So to create your architecture, all you need to do is figure out what each module is going to do, and then give them ways to communicate with each other.
Every application architecture that provides shared resources (such as a database) to its users involves a client and a server in some way. Since you need to generate web pages to create a web applicaiton, this can take two forms: client-side rendering and server-side rendering. Because your current application is using PHP, I assume that you’re using mostly server-side rendering. That architecture looks something like this:
Database <-- SQL --> PHP Web Server <-- HTML --> Web Browser
In a client-side rendering scenario, your architecture would look more like this:
Database <-- SQL --> Service Layer <-- JSON --> Browser App <-- HTML --> Web Browser
Your Service Layer could be broken down like this:
<-- SQL --> DAL <-- CRUD --> BLL <-- Business Methods --> Gateway <-- JSON -->
Where DAL is your Data Access Layer (i.e. a Data Mapper) that provides CRUD (Create, Read, Update and Delete) functionality, and BLL is your Business Logic Layer containing methods that encompass your business operations.
So where does Node fit in? In a client-side rendering scenario, Node would live in your Business Logic Layer. In a server-side rendering scenario such as the one you have, things get a bit more complicated; you’ll have to figure out how to get node to produce your web pages for you.
Anyway, the point of all this is to give your application boxes to live in. Each box can be designed, written and tested individually, separate from the other boxes. Your technology decisions can also be made for each box individually. When you’re done, you can connect all of the boxes together, do some integration testing, and have a fully functional, loosely-coupled, maintainable application.
Further Reading
Gateway
Service Layer
Data Mapper
Domain Logic and SQL
Server-Side Rendering with Node
2