As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I really would appreciate some concise advice.
I am about to embark on a project where we will be maintaining a lot of property data.
We intend to build the application with a RESTful interface so that various clients can connect. ie web app, iphone app, 3rd party api etc.
We really want the app/api to be fast, responsive, solid.
However, realistically we only have a certain amount of in-house skill-set and want to make sure our thought process is heading in the right direction.
Our core knowledge is PHP so our initial idea is a LAMP stack (maybe replacing mysql with Postgres) with Memcached. We are likely to use Laravel framework too.
However, we are toying with the idea of writing the software in RealBasic (similar to VB but proper OOP) and create bytecode. This would include the http server too - all be it simple compared to apache.
Is the latter overkill? Are we making it harder in the long run as our own http server will probably never compare in speed to apache.
I would really appreciate some thoughts.
The only way you would want to use a REALbasic HTTP server is as an app server sitting behind Apache -- it would be crazy folly to run a public-facing web site on some slapped-together HTTP server written in any language -- so you'll have Apache (or Nginx) in the mix regardless.
REALbasic can work quite well in that role. It compiles to machine language, not bytecode, and your HTTP server would be built on its asynchronous single-threaded server socket framework, so performance is generally excellent.
That said, I doubt it would perform any better than PHP backed up by caching (Memcached, etc.), and PHP is a much, much, much more mature technology for web development than REALbasic, with none of the obstacles or limitations you will likely encounter if you attempt a REALbasic-based solution.
I'd say PHP is the safer and better choice for you, in this case.
(Caveat: I wrote this answer while taking a break from writing a web app based on a REALbasic HTTP server, development of which has been nothing but sheer pleasure -- REALbasic is a lovely language.)
I'd stick with PHP if that's the skillset you've got inhouse.
There's always the option of compiling the PHP code using HipHop if really does come down to needing that kind of performance.
Writing your own web server sounds like a crazy idea -- if there's any single piece of software on your system where it's a good idea to have something that's well tested and secure, it's the web server. Writing your own is unlikely to perform as well as something like Apache or nginx even if you do write it as lightweight as possible, and it's almost certain to have major security holes.
Creating the web server using Real Studio is not all that crazy as you have a number of ways of going about it and you don't need Apache or IIS to do it. You can create a console app whose sole purpose is to provide the API to your apps or you could create a Web Edition app that can also serve web pages. It really depends upon what you want to accomplish with the web side. We've done both for a number of clients and it's worked well for them.
But, since you're already familiar with PHP I would say stick with what you know. Learning Real Studio isn't very hard but it's still a new skill set with all of the requisite bumps in the road for the things you don't know (yet).
Do you have a solid reason for writing your own webserver? If you don't need all the bells and whistles of Apache, maybe you could go with something smaller, e.g. nginx. Also, if you want to go with Linux I'd say that Basic (or any dialect) isn't the greatest idea. If you need bytecode, probably Java would be a better choice.
This is certainly not part of your in-house skillset, but for fast, lightweight RESTful APIs, I highly recommend Erlang and Cowboy
Erlang is a functional language used by telecom companies to run telephone hardware. It is highly fault-tolerant and, in my opinion, very expressive. It's optimized for concurrent execution, so you get all the benefits of multithreading without the headaches.
Cowboy is a webserver written for erlang. It's extremely lightweight, efficient, and easy to code for. I use cowboy to serve roughly 25,000 RPS per datacenter (~1200 RPS per machine) and it has never let me down.
If you're not going to use erlang, you're better off using apache or nginx. I would only use RealBasic if you're not writing your own HTTP server for it (just handlers).
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We have a website that originated in 2001, which started with some simple classic ASP scripts that enabled website viewers to dynamically configure products by following a step by step process of choosing product accessories, etc, using Access as the data source. The website expanded eventually to currently keep track of a simple, small encrypted member list with usernames and passwords to enable access to restricted areas of the website.
In the future, we're planning an expansion of the website and the backend will need an overhaul obviously to a more modern, scalable framework. The first inclination is to convert the classic ASP VBscript to VB.net. Another option would be to convert the backend functionality using PHP and MySQL.
Which would be easiest to convert to, simplest to maintain and scalable for a future expansion of functionalities?
It is a matter of preference and what the team is comfortable with. If you are better aligned towards ASP then stick to that and vice virsa. There is no 'right' answer or 'right' language for the job. They both do practically the same thing albeit in different ways.
There's lots of answers. If you already have developers, then a heavy influence would be what they are comfortable with.
If you don't already have a team, then there's lots of factors to consider. You need to learn the different languages, frameworks, platforms, & databases.
Languages. This is the set of core commands that the computer recognizes. Big ones are:
VBScript
VB.NET
C#
PHP
RUBY
Frameworks. Frameworks are large libraries that do a lot of the work for you. The core of the framework will still be one of the above languages, but there are also commands that call library routines. Big ones are:
ASP.NET & ASP.NET MVC (runs VB.NET, C#.NET, & other samller languages)
CAKE (runs PHP)
Ruby on Rails (runs Ruby)
Platforms. This is the type of server running your website. The two big ones are:
Windows (can run almost anything)
Apache (can not run MS products like ASP.NET)
Databases. Several good options here. Big ones are:
MS SQL Server (requires license to be purchased, and also requires
Windows)
MySQL (Free license)
MS Access (wouldn't recommend for anything but the smallest of
projects)
There are many, many more that could be listed. I tried to hit all the big ones.
Now, with all that being said, Ruby on Rails (RoR) is the most used for new development right now (according to Google trends). Lots of online libraries & help can be found.
PHP is huge, but is declining.
If you use ASP.NET, I would recommend using MS SQL Server as the a lot of the wizards fail when using MySQL.
If you use PHP, CAKE, or RoR, then MySQL would probably be more compatible with existing libraries.
Good luck with your upgrade.
IMHO PHP is equivalent to Classic ASP for many reasons, including that it is a scripting language. If you are going to move away from Classic ASP, rather than move horizontally, I would progress by choosing .Net or Ruby.
PHP is the easiest language for writing websites and it does not lack any needed features. Development is faster and cheaper with PHP. There are more PHP coders than .NET on account of the easy learning curve. Other languages may be "faster", but unless you have a very very large scale application this speed difference is irrelevant.
You will probably be making your site from the ground up and the difference in effort to "convert" your code won't matter.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm creating live chat application that should be part of my website. Website is fully developed using PHP. Now the problem is I'm in dilemma what would be the best appropriate tool for live chat application platform that will become part of my website. It should use Users from my website and share Session with PHP application it's part of.
I did some research and as I thought - PHP+Apache is not really the best tool for development of applications based on web sockets like my live chat is. Other platforms like Node.js looks like the right choice but I'm not sure how easy it will be to make Node to share resources with my PHP application.
I'm interested what approach would you use for situations like this? What architecture of the system would you implement?
For the end I want to tell you that my PHP website is MySQL based and I'm using knockoutJS for client-side implementation. It will use SocketIO on client-side because of it fallback strategies and support for non-HTML5 browsers. I know it can be used on server-side too but I'm doubting between it and Node or some other solution currently unknown to me. That's the main reason why I'm asking this question here. There is a small possibility that it will be running on shared hosting but I fully understand problems with shared hosting and socket connection (closed ports, no-SSH for installing Node etc.). If you have suggestions regarding this possibility - write it down. Otherwise just forget about it and answer like it's going to run on VPS.
Thanks.
If you plan on using node.js, there are solutions out there to help integrate node.js into your existing php environment. (e.g. Sharing PHP sessions with node.js) Node doesn't play to well with apache, so you will probably want to look into switching over to Nginx and PHP-fpm.
Personally to get this running "well" that is a good amount of changes for just a simple "chat" application. I would probably look into integrating an already developed solution Comet Chat. Or if I wanted to make it a little more customized I would build out something that uses an existing architecture on a separate platform. Firebase is a pretty awesome service that just came out that looks like it would fit your needs perfectly. If this worked out as a good solutions for your users, I would then work implementing something custom built in Node.JS.
A in-house solution would start with evaluating the needs for your server. How many concurrent connections do you expect? Do you have control over low-level Operating System features. Open socket and open file limits seem to be major contributing limitations to shared hosting plans. So you may need to evaluate different hosting plans. A good PaaS solution for Node & PHP is AppFog. Appfog is free for up to 2gb and 10 instances, which may help you get started. If you want total control I would recomend a dedicated server, or something like amazon AWS.
Then you will need to evaluate your architecture. Like I said, Nginx does a pretty good job how serving both PHP and node.js, but there are many more options that may better serve your needs.
A good place to look and start learning is the source code of Ballons.io. It is a very well written open source chat, and it leverages redis, which is a common solution to session management between PHP and node.js. Best of all you build the source on AppFog, and test out some in-house solutions and code in minutes without any cost to you!
Good Luck!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I have opened a large web project on elance for a social network. I got over 30 bids on my project and many of the providers recommended php even though they had .net knowledge. many have said that php with drupal has many advanteges over the .NET framework but did not say what they were. Its hard to believe that a scripting language has advantages over a compiled language. Am I missing something here.
PHP will run on essentially any server, for free. That's a fairly compelling feature for many folks.
There are lots of pros and cons of both, and it certainly doesn't boil down to scripting vs. compiled (incidentally, opcode caches like APC and things like Facebook's HipHop even the score on that point).
I'd say if someone's recommending PHP over ASP.NET, they code primarily in PHP. If they're recommending ASP.NET over PHP, they code primarily in ASP.NET. There's probably not much more to it than that in the responses you're getting.
Ugg, the weekly PHP vs ASP/.net argument. Let me frame it this way:
Both work. Well, actually.
Neither is really more "enterprise grade" than the other.
.Net developers (at least in my area) tend to make more. That being said, the Government "drank the microsoft Koolaid" and most jobs in my area are for government contractors. It may be different where you are.
PHP really doesn't have a great GUI yet. Not an issue to those of us who are command-line types, but it could be for you.
.net solutions tend to be relatively unified since Microsoft is driving the bus. There's about a million different ways to skin a cat in the PHP world because it is relatively fractured.
In my experience, PHP tends to be better documented with many more how-to's online. If you disagree, you might be a writer for Microsoft's tech net, which is written partially in some alien/geek mashup dialect of English.
MANY php how-tos and forums are frequented by non-native English speakers, and entire projects can be frustratingly impossible to understand because of the language barrier. It seems that Europe has picked up PHP at a higher rate than those of us in the States.
I was indirectly involved in a Microsoft Case Study that I think illustrates the difference. I worked at one Olympic non-profit on a php-based site. They opted to standardize on Microsoft and move to an entirely .net/sqlserver based. I moved over to another nearly identical non-profit (just a different sport) who was embarking on an in-house build of a PHP-based website with nearly identical functionality to the one I left.. The .net website, when completed, cost $1.5 million, involved 16 servers, and required 3 additional full-time staff hires to extend and maintain. The same level of service, programmed in-house by 3 guys on PHP in a shorter amount of time ran on 3 servers (two application, one MySQL DB) and cost about $25k when all was said and done. Microsoft published the .net solution as an official Microsoft Case Study success. You be the judge....when you compare the solutions, I'm not sure they're even. Both serve nearly identical traffic and process very similar amounts of money. I know where my time and money would go.
The most significant advantage of PHP might be that it is free and you can start developing it without having to install too many things. (Apache, PHP and an editor)
After working with the Prado framework for a while, I don't see any big differences with it anymore.
OF Course : Visual Studio makes developing and debugging ASP.NET apps a dream.
I tend to prefer c# development to php development, but both are perfectly valid choices.
One of the main advantages php has over asp.net is just the volume of ready made components, controls, libraries, and frameworks out there that are available for use.
It is entirely possible that your project could be assembled in php much faster than in asp.net if the right tools are available.
It doesn't really matter if you choose PHP or ASP.Net, both can deliver, both have a solid base, both are proven technologies. PHP is a mite cheaper, but ASP.Net is getting there.
Unless you're going to maintain the app for a long time ASP.Net's superior OOP capabilities aren't going to offer you much advantage. But if you've got a non-trival app then the multi-layered ASP.Net approach might be helpful.
Just get the coder you're most comfortable with.
I would choose ASP.NET mainly because of Visual Studios, makes programming a lot easier.
I would choose PHP mainly because of variety of frameworks, such as CodeIgniter.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
For those of you who have had the opportunity of writing web applications in PHP and then as an application server (eg. Python-based solutions like CherryPy or Pylons), in what context are application servers a better alternative to PHP?
I tend to favor PHP simply because it's available on just about any web server (especially shared host), but I'm looking for other good reasons to make an informed choice. Thank you.
I have a feeling that some of the responses didn't address the initial question directly, so I decided to post my own. I understand that the question was about the difference between the mod_php deployment model and the application server deployment model.
In simple words, PHP executes a given script on every request, and the application has no knowledge of what has happened before (unless it is emulated somehow). Moreover even the source code is being parsed on every request (unless you use a bytecode cache like APC). This process can be slow, especially if you have a framework with complex initialization.
In contrast to this, the application server has to be started once, and then it waits for a request to be processed. The application server should clean up resources after every requests (allocated memory, open descriptors, etc.), it can also pool certain resources (like database connections) that can be reused between requests for extra performance.
This later model (application server) is more efficient in most cases, but on the other hand more difficult to setup and maintain. It is also more demanding, as you have to pay more attention to the resources you utilize, in order to avoid resource leaks.
The advantage of deployment for PHP is a huge one. You will also have a large developer base, and sound like you already have considerable expertise. In general if you know how to use a programming language well, you are safer to stick with it.
The advantages of using a Python web framework like Pylons are that your code will be neater, and more maintainable. Of course this is possible with PHP, but seems much harder to achieve. Python is simply a nicer language than PHP, so that might affect your decision.
Personally, I would not describe either Pylons or CherryPy as an "application server", if you want a Python application server, try Zope. (They both do serve WSGI Applications, but that is a topic for another question.) There seem to be plenty of equivalent frameworks for PHP, and they have been listed in other answers.
There are several products in PHP which fill the same space as CherryPy or Pylons.
(except, of course, they don't run Python ;)
Have a look at -
CakePHP - http://www.cakephp.org/
Symfony - http://www.symfony-project.org/
Code Igniter - http://codeigniter.com/
Zend Framework - http://framework.zend.com/
Personally, I prefer Drupal, which works as a great framework and comes with a lot of CMS and community site features out of the box. The ones above are quite different in many ways, but any of these should offer you the best of both worlds if you want an app framework / appserver that runs on PHP.
Drupal - http://drupal.org/
Which one is the right choice is largely a matter of taste, although each has its various advantages and disadvantages.
There are many more - these are just the ones I've heard good things about from colleagues and collaborators. It's not a complete list.
Python web-apps tend to require more initial setup and development than the equivalent PHP site (particularly so for small sites). There also tend to be more reusable pieces for PHP (ie Wordpress as a blog). Configuring a server to run Python web-apps can be a difficult process, and not always well documented. PHP tends to be very easy to get running with Apache.
Also, as PHP is very widely used and is heavily used by beginners, there tends to be very good documentation for it.
However, Python is much more fun, and much more maintainable. It scales well (in development complexity terms, rather than traffic).
Personally, I would also say that using Python tends to train you to solve problems in a better way. I am definitely a better developer for having learned the Pythonic way of doing things.
Using application servers like Pylons, Django, etc. require much more work to setup and deploy then PHP applications which are generally supported out of the box. I run a few Django apps and had to learn a bit of configuring apache with mod_python in order to get things to work. I put forth the effort because coding in python is much more enjoyable to me than PHP and after you get the Apache config right once you never really have to mess with it again.
On another note, if you decide to go with a framework like Django, Rails, Pylons, .... they tend to solve a lot of small repetitive tasks that you would otherwise do on your own. But frameworks are their own huge topic of discussion.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for some quick thoughts about a business application I am looking to build. I'd like to separate the three layers of presentation, domain logic, and data using PHP, Python, and PostgreSQL, respectively. I would like to hear, possibly from other folks who have gone down this path before, if there are problems with this approach, if I am targeting the wrong tools, etc.
I'm looking at PHP because it is widely used, fairly mature, and I can find ample people with skills in PHP interface design.
I'm looking at Python because of the benefits of readable code, because I hear can find more Python programmers that also have subject-matter skills (in this case, finance), and it's an open source language. Plus, it seems easier to code with.
I'm looking at PostgreSQL for the transaction-level features. MySQL is also an option here, but I don't need to debate this aspect.
This is not a web application, although I would like to utilize a browser for the user interface. This is more of an Enterprise Application, but for a small business with moderate numbers of users (maybe 5-10) and a modest number of daily transactions.
What is important is that we are able to upgrade the database or domain logic or interface separate from the other layers in the future.
I'm NOT looking for a buy vs. build debate, as that's a different discussion.
Thanks for any insight
Look at Django.
Python code. A template language that permits some of the same features as PHP -- slightly different syntax.
Model is divorced from view functions ("business rules") and divorced from presentation. This is enforced throughout Django.
One of the common questions is "why can't I do -- some crazy PHP-like thing -- in the Django template?" The answer is that presentation is not processing. Do your processing in the Django view functions. Render the results as HTML in the template.
Also, Django has an ORM layer to divorce you from petty SQL considerations. MySQL or PostgreSQL are more-or-less equivalent from within Django.
Edit
"Maturity" means a lot of things. You specifically mentioned skilled people as a sign of maturity.
Django is pure Python. If you can find Python people, they can learn Django in a few days. They just have to do the tutorials.
A Django-powered site is usually Apache + some glue + Django. The glue can be mod_wsgi or mod_python or mod_fastcgi. You have to manage this configuration with some care because there are several moving parts. This, however, is the same Apache config problem you have with PHP -- nothing new here.
A Django site has one or more Django server instances, each with a settings file, a URL mapping and any number of applications. Pure Python at this point.
A Django application has URL mappings, model and views. All pure Python. Unit tested with the Django extensions to Python's own internal unittest framework.
The model uses an ORM layer. This may, perhaps, be the single most confusing thing in Django. People sometimes design very odd models because they think either too high-level-uber-generic or they think too much in SQL. Django is a middle ground of mostly object-orientation with some SQL consideration. Get this, and you're unstoppable.
A Django application may have templates, which are in their own template language. This would be about the only non-Python thing that's of much interest. You may want to add custom tags -- pure Python.
You'll probably have JavaScript (also true for PHP and every other web application framework). Nothing new here.
Since Django's admin application automatically handles basic CRUD processing, you don't have to write this. You are free to write all the transactional stuff you want. But you don't have to. This leads you to a very, very powerful hybrid.
You write a few complicated, critical transactions. Pure Python, BTW.
You don't write any of the dumb table-maintenance transactions. No code at all is superior to Python or PHP.
After you get your feet wet with the template engine and CSS's, you can tailor the admin interface to look like anything you want. This is HTML/CSS stuff, no Python or PHP.
Bottom line. Most of the skill set is Python. The ORM is -- syntactically -- Python, but requires some care in doing things simply and cleanly. The template is it's own language, but considerably simpler than PHP. The rest is SQL, Javascript, HTML, CSS, Apache and what-not.
Edit
Django Maturity
See http://www.djangoproject.com/community/ for the number of active projects.
Join http://groups.google.com/group/django-users for daily flood of emails from users.
The Django blog stretches back to '05, meaning they had years of solid experience before finally releasing 1.0 in September of '08. Development apparently began in '03.
I'm going to assume that by "business application" you mean a web application hosted in an intranet environment as opposed to some sort of SaaS application on the internet.
While you're in the process of architecting your application you need to consider the existing infrastructure and infrastructure support people of your employer/customer. Also, if the company is large enough to have things such as "approved software/hardware lists," you should be aware of those. Keep in mind that some elements of the list may be downright retarded. Don't let past mistakes dictate the architecture of your app, but in cases where they are reasonably sensible I would pick my battles and stick with your enterprise standard. This can be a real pain when you pick a development stack that really works best on Unix/Linux, and then someone tries to force onto a Windows server admined by someone who's never touched anything but ASP.NET applications.
Unless there is a particular PHP module that you intend to use that has no Python equivalent, I would drop PHP and use Django. If there is a compelling reason to use PHP, then I'd drop Python. I'm having difficulty imagining a scenario where you would want to use both at the same time.
As for PG versus MySQL, either works. Look at what you customer already has deployed, and if they have a bunch of one and little of another, pick that. If they have existing Oracle infrastructure you should consider using it. If they are an SQL Server shop...reconsider your stack and remember to pick your battles.
I can only repeat what other peoples here already said : if you choose Python for the domain layer, you won't gain anything (quite on the contrary) using PHP for the presentation layer. Others already advised Django, and that might be a pretty good choice, but there's no shortage of good Python web frameworks.
I personally agree with the second and the third points in your post. Speaking about PHP, in my opinion you can use Python also for presentation, there are many solutions (Zope, Plone ...) based on Python.
Just skip PHP and use Python (with Django, as already noticed while I typed). Django already separates the layers as you mentioned.
I have never used PgSQL myself, but I think it's mostly a matter of taste whether you prefer it over MySQL. It used to support more enterprise features than MySQL but I'm not sure if that's still true with MySQL 5.0 and 5.1. Transactions are supported in MySQL, anyway (you have to use the InnoDB table engine, however).
Just to address the MySQL vs PgSQL issues - it shouldn't matter. They're both more than capable of the task, and any reasonable framework should isolate you from the differences relatively well. I think it's down to what you use already, what people have most experience in, and if there's a feature in one or the other you think you'd benefit from.
If you have no preference, you might want to go with MySQL purely because it's more popular for web work. This translates to more examples, easier to find help, etc. I actually prefer the philosophy of PgSQL, but this isn't a good enough reason to blow against the wind.
Just to throw it out there... there are PHP frameworks utilizing MVC.
Codeigniter does simple and yet powerful things. You can definitely separate the template layer from the logic layer.