I am creating a website which uses PHP on its back end. Now I am adding machine learning capabilities to my website which are accessed by HTTP methods GET and POST. But since sklearn is in Python, how do I enable my PHP code to call python based sklearn code? Or is there a way I can use some library to call Python code?
One possible option for you to consider is: https://github.com/nok/sklearn-porter
I think you can achieve your goal, without calling python code directly (embedding it) from PHP code.
For example, let's suppose you have a web application, which is built using PHP, and your application contains Articles, and you want to add the feature of categorizing (tagging/classification) of those articles into some categories: News, Sport, Medical, Science, etc ...
let's say that you have built a machine learning model using sklearn (possibly naive Bayes model), which predicts the probability of each category. and you want to use this model within your application.
Now, you can export this model as an API, and make other applications use it, in our case, your web application will send the Article to this API, and get a list of predictions for each category.
For building API in python you can use: Flask-RESTful, or Django REST
While this approach has some disadvantages, I think it's much better to design your application(s) with modularity in mind, keeping each service (functionality) separate from the other, makes your system more loosely coupled.
Related
I'm thinking of using a php cms, a php framework or php code generator. A php cms is restricted somehow and with a php framework and a php code generator I have more freedom. But what exactly is the difference between a framework and a code generator or what do a framework share with a code generator? I'm also planning to use Scriptcase 5 for a project because I already have the licence and I don't want to use a cms or something similiar that can limit me.
With a code generator such as Scriptcase, you do not have to write PHP / HTML code to create a data-driven web application.
However, if you want to extend the default features of the web application generated by a code generator, this will be painfull and you must have both time and deep understanding on how PHP and the generated code works.
If you want to create a website/blog/publication web app => use an existing CMS (do not re-invent the wheel)
Otherwise:
If you don't have the time and/or you don't know how to develop a web application => use a code generator
If you want to create a complex web application => learn how to develop (if needed) and use a framework
CMS, framework and PHP code generator are three different beasts.
CMS is a software tool tailored to allow easy website editing/maintenance. Most CMS use databases though there are file-based ones as well. Popular CMS are Joomla, Drupal, CMSMS and Wordpress to some extent. You can use CMS to maintain your website however building a web application like Twitter or Facebook won't be possible. CMS is not a tool, this a web application.
Both framework and PHP code generator allow you to build web applications. With framework you still need to write the actual code. PHP code generator will generate 50-90% of code for you.
Lets use an analogy. You need to build a car. Writing code manually means building a car from scratch: building your engine, your transmission, writing the software for car computer etc. It will take many man years to build one.
Using framework is similar to buying DIY kit. You get engine, body, wheels and just need to assemble it. Depending on your skills this can take up to few months.
Using PHP code generator is similar to pronting your car on 3D printer. You choose the program, select make/model/options and click 'Print'. Some time later you have your car. You might be able to customize it to some extent. You can even buy another engine and replace the stock one.
And CMS is the car. You can paint it different colors, change wheels etc. If you need another car, you have to get another CMS.
If you read that far you deserve to know that the best PHP code generator on the market is PHPRunner.
Code generators are best to develop Database management systems. They save you lot of efforts in writing lengthy code for almost similar tasks. Some of the Code Generators do amazing work for you with just few clicks.
Also maintaining the project becomes very easy with these generator for everyday customers requirements
I recommend Scriptcase if you want a make simple projects with cruds and so on. For complex project you will need more flexibility and Scriptcase doesn't flexible. I worked with Scriptcase for 7 years and it's amazing.
I have different questions about a full architecture idea. I hope someone with great experience could help me out because I am pretty much getting stuck in all possibilities.
I'm planning to rewrite a community website. Our customer wants to make use of native mobile apps in the future. So I will need to take this into account. Because of this I have decided to create a 100% REST API architecture based on the PHP framework Kohana. I have choosen Kohana because this makes scaling the internal API to a other server very easily without much extra effort. (Kohana threats internal url requests not as HTTP so there isn't much overhead in the beginning and can scale to HTTP with some minor code changes).
At first the API will be private, but later on we might make it public to let more services connect to us easily.
De basic REST structure is as follow:
/cats
/cats/1
/cats/1/custom
'custom' could be 'childs' for instance.
same goes for:
/ads
/bids
/users
/banners
etc..
These are perfect entities for the API because the mobile app will definitely use all this functionality.
So we can conclude the core of the website is REST. So basically I want to make the website a client of the API just like the native app in the future. This way maintenance seems much easier.
What worries me though is the fact that there is much more than this (managing uploaded files, invoicing, automails for invoicing, automails for ads and so on). Uploading files needs to go through the website to the API. Is this common practice? If I do not do this, the website would do upload logic, which makes the site no client anymore and the app itself. Hence the mobile app can't even upload and both API and website need to know the upload folder (duplicate logic).
I thought of creating the following modules:
community-api
community-website
Api seems to be the core then. But.... what about cronjobs etc? Actually they should not be part of the website, as this is just a 'client'. I feel they should interact directly with the model or API. So basically the API gets more like a gateway to the core and thought I need this:
community-core
Models
Cronjobs
Auto Mailings (part of cronjobs)
Invoices etc
community-api
Interact with models in core through HTTP
community-website
Website
Admin
The core cronjobs are a exception to the REST structure. They are the only one that can change data without going through the api. At least that was my idea because they belong in the core and API is on top of the core.
But by design that seems just wrong. Manipulating should only go through the API!
Alternative:
community-core
Models
community-api
Interact with models in core through HTTP
community business
Cronjobs
Auto Mailings (part of cronjobs)
Invoices etc
community-website
Website
Admin
This look better by design to me.
(source: mauserrifle.nl)
Main Questions
1)
Should cronjobs manipulate through the API or Core models?
2)
My invoice cronjob needs a template pretty much the style of main website of course. But if my cronjob is part of business or core it won't have knowledge of my main website. What makes sense to solve this?
3)
My website will be using mustache as a template engine. (both php and javascript can parse these templates). I thought using the api directly for ajax calls but then realized:
The site gets data from api, formats timestamps to dates (Y-m-d) for the template and then renders. If I let javascript call the api directly, javascript must have logic too (formatting). This is duplicate code! Feels like the only solution is calling the website for ajax (which calls the api and formats) and returns the formatted json. Am I right?
But.... simple calls like deleting a ad can go through the api directly (e.g. DELETE: /ads/1
I get a mix of calls....
Any better solution for this?
4)
Overall: Is my architecture too complex? Any alternatives I should consider?
I would love to hear your feedback!
Once I've heard that a good way to develop a web application is to develop an API-Centric Web Application. The thing is, to me, if you couple the main service to the public API, building an API-Centric application, you lose the whole point of developing a public API at all.
This doesn't seem logical to me.
Yes, the API and the website and what ever might come next are separate things and website should be a client to the API itself but since it will simplify things greate, I believe that you should RE-USE the domain-classes to build and base your web-site logic. This way you can use all the same code base and handle all your issues including ads, invoicing and of course file uploads with ease.
For the public API, it should be on a separate box if possible re-using the same domain classes but with different authentication methods so that whatever problem might occur, it won't affect the main service.
Your cron-jobs should only be used to fire the call through the API itself and those calls should be made on the main app (website through the API)
If you build your website without repeating-yourself, as in, using the same code as the base and wrapping the web-app around it, you won't have the issue raising in q#2.
Same thing applies for question number 3. If you wrap the website around the API, the website can use the api itself without being a separate entity.
Your architecture seems complex but if you do these things, it will be simple. ;-)
Good luck!
REST is just one way to initiate a request. Your core code that processes the request shouldn't be tightly coupled to the REST interface, or HTTP for that matter. I would advise designing your REST API as a simple mapper to an include file or something similar. Your cron could then bypass the whole REST API and just include the file directly. Separate the request interface from the code that does the actual processing.
I'm developing a web application and I'm using PHP and Javascript. Today, I'm starting to draw all the design class diagrams, but I don't know exactly how to mix both technologies.
I think that something like the following should be good:
But, really, I'm not sure if typing the .php extension in the class name is sufficiently clear, or what I need is to separate diagrams in two: one for Javascript classes and another one for PHP classes.
I'm using CodeIgniter (MVC pattern) and Javascript. Any suggestion will be really appreciated.
Thanks!
Usually, you don't want to do this. It's a problem of latency when viewing the web page in a browser. Each separate javascript file defeats caching and requires additional transfer time before a page can load. It's commonly advised to combine JS files wherever possible and practical to better take advantage of browser caching. So my first suggestion is to not arbitrarily split up your JS for architectural reasons...
Now, with that said, to answer you question in entirety, I think it depends on how you view JS. If you're looking at it form the perspective that it enhances your PHP application, then dividing it up along side your views is not bad (the above suggestion not withstanding).
However, I usually see JS as a separate application layer on top of the PHP application. The JS interacts with the PHP layer through defined APIs. So it's basically just a full blown GUI application that just so happens to use the API defined by the PHP application. So with that in mind, I usually build the JS application with its own architecture that's more dependent on itself then the PHP application. So in other words, just because a piece of the JS application interacts with PHP doesn't mean that the piece of code belongs with the PHP application.
Does that make sense?
Trying to put all your classes (even within one application - you have two: a PHP applicatoin and a JS application) on one UML diagram is pretty much a way to waste a lot of time and gain nothing.
Use UML to show dependecies within a package or a group of classes working together, but don't try to do it for a whole app.
I don't know the way you do things usually but in my projects, I tend to separate PHP and JS. First of all, its easier to develop and debug if you go that way, secondly, if you treat javascript as a second layer instead of being on the same level of programming as PHP you will get a working fallback in the case that your JS doesn't work, or the user of your web app have javascript disabled.
I tend to make everything work in PHP and later on I override some actions with javascript to get them working through ajax instead of the traditionnal way of working in old school Web.
--- Revision following first comment ---
Then, you might want to treat the PHP and the Javascript part as separates applications. The first system (PHP) generate the initial state. Upon user action the second system (JS) makes a query to the first one and wait for the answer, this way, you will setup some sort of API that will standardise your transactions.
I used to work with design information specialists and they often refer to Jesse James Garrett as a "Guru" in that field of expertise, you might want to check his site (there are premade stencils for omnigraffle, visio and few others).
Through his writing and example you might be able to find the right symbols and elements to represent your system.
Jesse James Garrett's website
I have an existing website written in PHP. I would like to add a REST API. I like how easy creating a RESTful API was using Django. Are there any CONS for using Django for the sole purpose of creating an API on a PHP powered website? Thanks in advance.
There are a couple of cons:
your codebase will be larger
every change in the data model on one side must be done on the other side aswell
it will require more resources from your server
you have 2 systems to maintain
But for the rest, I can see why it would be easier to do this with Django than it would be to do with a plain PHP API. I have my doubts that there are no PHP libraries available to do something similar though.
I love Django, but I'm not sure that it would benefit you here. Maybe I don't completely understand how you plan to use it, but it seems like if you already have your data access and logic done in PHP then you would have to re-code that in Python in order to leverage Django.
If what you really want is clean urls and simple url mapping then you could probably use CodeIgniter or CakePHP. That way you don't need to rewrite your existing code in Python or having the same code in 2 different languages.
This may sound odd but a right answer might save me hours of coding. I have found a ruby-on-rails class (~10 files, ~1000 lines total) that serves a specific purpose (payment gateway integration). However, I am not familiar with ruby at all and need to use that class in a PHP application. I am wondering if there is a program that can perform the conversion for me. I understand that some portions of code might need to be hand-edited which I can manage.
No, there is no commercial, free, or open source compiler that will take any an arbitrary piece of ruby code and compile it into PHP.
The other answers are suggesting you learn enough ruby-on-rails to create a simple rest framework on top of the existing ruby code, and then use curl (or some other http/web services library) from PHP to fetch and post to URLs in your new simple rails application. These requests would trigger methods in the ruby class, which would run within ruby. There would be no direct eecution of ruby code by the php run time.
My suggestion is you'll spend less time finding payment gateway code written in PHP and using it instead.
It's quite easy to talk to a Rails app.
You could talk to it through REST calls, which is basically sending a HTTP method to an URL.
For example, a /GET to /products.xml would return you a list of all products. A /PUT to /payment/new with the appropriated params would start a new Payment model, etc.
Take in mind you'd need to know how it works, what models it has and what routes are there available on it. Luckily, Rails comes with many tools. One of them is a rake task called routes.
Execute "rake routes" and you'll be returned a list of all the URLs that Rails works with, with the needed HTTP method and supported params. With this info, you could find out how to talk to that app.
Gotcha: PUT and DELETE are both HTTP methods that currently browsers doesn't implement largely, so Rails uses a _method param. If you send a POST method with a _method:"put" param, it will proceed to act just as a /PUT method was sent.
There are no software out there to do such a thing.
You could interface with it or just take the business logic out of it and redo it from scratch if you're not familiar with Ruby on Rails.