3

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.

5 Answers5

4

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.)

WaltPurvis
  • 1,510
  • 12
  • 14
3

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.

SDC
  • 14,192
  • 2
  • 35
  • 48
  • In that case: PHP with Laravel OR Node.JS Any preferences? – user2007960 Jan 25 '13 at 11:58
  • 1
    @user2007960 - given the choice as a developer, I think I'd go with Node.js, because it's always good to work on the latest thing. But as a company, I think I'd pick PHP, because it's well established, has more support structures available, and easier to hire devs with experience. – SDC Jan 25 '13 at 13:33
3

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).

BKeeney Software
  • 1,299
  • 6
  • 8
  • Thankfully I know both software pretty well. Realbasic developers have pretty decent example of an http server including session management that I have played with - but not tested in the wild. So i dont know what capacity it can handle. I would do exactly as you state. Create it as a console app, listening on a port and responding with JSON. Have you found any significant reason to use one over another. I love to hear more of your experience with creating an RB server interface. THanks. – user2007960 Jan 24 '13 at 18:08
  • The http server example, I believe, is the basis for Web Edition (obviously grown many times since then). You can do the exact same things you want to do with the console app as with Web Edition (with some URL restrictions). The added bonus is that you get GUI web pages as a bonus. We made a nice web store interface to a desktop app using the WE special url, but also had an admin GUI. Eventually that interface may get extended to do an authors type GUI. – BKeeney Software Mar 04 '13 at 19:35
2

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.

schaiba
  • 362
  • 3
  • 11
  • I do not consider Java as a better choice, just because of the resources and the application/API resulting speed. Have worked with many Java web apps neither of which was *fast*... In other words - many times I consider a website/webapp slow/laggy and look into the browser's address bar, I could see `.jspx` or `.jsp` at the end... – shadyyx Jan 24 '13 at 15:49
  • Java is faster than PHP if built correctly. But use the skill set you have, APC will cache bytecodes generated by PHP. – datasage Jan 24 '13 at 16:00
0

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).

Soup d'Campbells
  • 2,333
  • 15
  • 14