i need to build index server for p2p (games) application
can i just use web server(lighttpd) and extend it with some plug in?
is there any problem with this method?
Twisted is a framework for creating network applications. It's written in Python. You could use this to write your indexing server.
Not knowing any more about what kind of server you are wanting to write makes it impossible to say anything more, but it is unlikely that you can just extend an existing web server with some plugins.
Related
I was recently developing a socket based system using Lua which was quickly turning into a web server , I wrote a small API which is tightly coupled with the socket logic and I found myself with everything that I needed to have a full fledged API service without worrying about everything else that a conventional web server is usually bundled with. Since I was using OpenID I discovered I don't need a cookie parser in the server logic and since I was only serving JSON data , I skipped implementing file management utilities which by the way are almost 30% of any decent server design.
I think what I developed ended up being a small framework that serves my JSON API , I stress tested the code and I could do up to 10K connection simultaneously since I was am asynchronous sockets and the load on the development computer was alright by me.
Is it advisable to design this way? , I mean I cannot get any good examples from companies that do this from a quick google search but I am sure there are those who do this. I am impressed by the simplicity that I got and the quick design time, most of the time I have to study complex web server internal things in order to accomplish such a task but having written everything incrementally , I seriously discovered that the learning curve is much shorter.
My entire code base is reasonably small excluding the Lua runtime and I can run a twitter like micro blogging service with exemplary error handling via the API. I am now designing the API front-end which will run on a full fledged web server (NGINX) ... I would really like to know if Implementing the API back-end on a dedicated custom stack is the best way to go or maybe I am setting myself up for some pretty crazy surprises in the long run.
I would like to use MongoDB directly at client side of an Mac OSX app, i.e. I want to store my models in a mongoDB. Is this possible? Most of the documents I saw explained how to access mongoDB that is present in a server.
There are undoubtedly a lot of other options for databases, even Mongo-like databases, but if you want to use Mongo on the client, by far the simplest way is to run Mongo as a separate process on your client machine. Using Homebrew or the 10gen Mac installer you can have it running in a few minutes. By default the server doesn't require authentication, so there's almost nothing to configure.
I wrote ObjCMongoDB. Using that it's simple to interact with the local instance.
A local instance plus a driver is the same way you'd build an application if you were required to use say PostgreSQL or MySQL – though again, there are other options for databases. It's perhaps a little easier with Mongo since collections just pop into existence when you start using them.
There's not an easy way to embed Mongo into a Cocoa app.
If you want something like MongoDB running on the client side, I'ld recommend you to use ejdb instead. It's specifically built for that purpose.
It aims to be a fast MongoDB-like library which can be embedded into
C/C++/NodeJS/Python/Lua/Java/Ruby applications under terms of LGPL
license.
I just discovered this Language and I'd like to know if it's possible to make basic CRUD web app using a database.
There are libraries for mysql and postgresql, and the core library provides a web server with HTTP, HTTPS and WebSocket support.
There is a templating library which isn't part of the official release. And, there is also a community mustache port (I don't think it builds at the moment, so you may need to fix it).
So it's definitely possible. But you'll be an early adopter. If you want to get stuff done quick, I'd choose something else, but if you're wanting to learn new skills, dive in.
Sure. It's a pretty new language though so you aren't going to find the robust library support you will in other languages just yet. It's rapidly growing however so I don't think it will be long. You can either write your server in dart or write your server in another language and expose a basic HTTP interface for your Dart client to consume.
Here is an example of writing a simple web application which creates and stores "blog" posts. Both the client and server are written in Dart. The database is MongoDB.
Also check out this question for more information.
Many applications use the following model:
Browsers or other clients interact with application servers.
Application servers (web servers or RPC servers) interact with data store servers (SQL servers or non-SQL storage).
For internet applications, they need application servers because they must keep simple feature on data servers for performance. But I can't see why they need application servers on intranet.
For example, can we develop an Adobe AIR application, which directly connect to a PostgreSQL server? I guess we can deploy a center PostgreSQL server which has many stored procedures and set strict permission, and let the Adobe AIR application fetch (and modify) data only by invoking the stored procedure.
Why don't the most of applications choose a simplier solution?
In general, there is no reason why you couldn't get an independent application to talk to a PostgreSQL server directly. Some applications do this and it works fine.
I'm not familiar enough with Adobe AIR to say whether it's possible in this context. In principle, if you can get a PostgreSQL driver, or if you can write your own using TCP sockets (the PostgreSQL network protocol is documented in details in the official documentation), you could certainly connect directly.
This being said, having a form of application server between the end-client and the database server isn't purely for performance.
Web-based development allows the SQL queries to be controlled by the server. Instead of exposing complete SQL access, you expose the features that the client can use. If you need to tweak the queries later (bug, change of data structure, ...), you can do this rather centrally on your application server, without having the need to deploy a new version of the client to each user.
Of course, you can do some abstraction like this user server programming directly, but this isn't suitable for all applications. This may depend on what other features your application needs, for example if it needs to make use of a library programmed in another language. You can use some procedural languages bindings, but it's not always suitable: pl/Python is an "untrusted" language (which may cause security problems) and pl/Java needs a external add-on, for example.
In addition, not all applications are ultimately reserved for intranet usage nowadays. It often makes sense not to restrict yourself to intranet usage when you start designing an application.
I initially started with a direct access design and quickly found it useful to move to an application server where I talked to the DB via web services. Reasons included:
Handling DB restart, local connection loss, client IP address change, etc is much easier when you're talking to the DB over a stateless protocol like HTTP. This is more of an issue for remote workers.
Transactions are clearly demarcated and isolated in server-side transactional methods (I used EJB3 and container managed transactions)
It's much easier to add new clients like a phone app as they can share more of the code and business logic. Stored procedures in the database are very useful, but can be limited and occasionally frustrating.
Some tools/languages don't have built-in tools for talking to PostgreSQL directly, but can easily talk to a RESTful web service with XML or JSON request/response format.
DB admin is easier if you're dealing only with a single application server connection pool
The main downside is of course the extra layer means extra work and extra maintenance.
You can, but...
Browser languages/libraries tend to have poor database support
What happens when someone wants to use this application remotely?
If you're not talking about browser-based applications, then that is exactly what many do. There are plenty of traditional installed client applications talking to a backend database either directly or via a wrapper (odbc/jdbc).
I am looking to develop some web app for my Android device. Found Sencha and think it might be a good tool to try out.
I suppose I would need to find a web server to host the Sencha app to run the app? What kind of web server is needed? I suppose one that able to run HTML5, CSS, Javascript is enough?
Can anybody recommend one (free one)?
Thanks.
++++++++++++
Thanks for the answers to the above post. I am new to this stuff, so got some more follow-up and somewhat related questions:
1) I read from the Sencha site that the app can be developed locally using things like XAMPP installed on local Windows PC. Question -- Why need this local host when I can just use an external Web Host?
2) It was also mentioned that for Windows may not need XAMPP if Window's Internet Information Server (IIS) is already running. How do I know if my computer is running this and so don't need to install another local server? (I asking this because I had installed an XAMPP before on another computer and things got quite messed up and so I want to avoid doing it if possible).
3) Once I got a web host, to have an app running, I would just have to have the JS files in the web host together with the Sencha framework right? If so, then I don't understand what is meant by "Build" in the Sencha documentation.
Thanks.
Sencha Touch is a client side framework, therefore there are no server side requirements. That said, any web host should do.
However, I'll go ahead an make a recommendation... a LAMP stack (Linux, Apache, PHP, MySql) will work the best. Of course you can substitute any of the stack for something of your favor, this setup seems to be the most favorable. Some of my colleagues utilize Ruby/RoR instead of PHP, so as you can see it is quite flexible in terms of environment.
When searching for a hosting provider, do your research and select something that fits with your budget but still gives you the best bang for your buck. Be sure to ask them questions!
Tip: Make sure you have access to your web server's configuration file so you can add mime_types and make other mobile oriented tweaks if needed.
First you must know that HTML5, CSS and Javascript are all front end stuff that do not count when you talk about Hosting. These are taken care of by the client agent (browser).
What really matters is your server side language: PHP, Python(Django), Ruby, etc.
So it mainly doesn't matter which framework, as much as which language that framework use.
This is a generic answer that will help you decide not only in terms of Sencha but for any other framework.
Take for instance WordPress. It uses PHP and MySQL, so first I look if my Web host supports Mysql and PHP and in general this would be enough to know that I can use if for my WordPress site.
And by the way, most Web host companies allow you to ask them questions before buying. So go ahead and question them about anything that concerns your requests.
Sencha provides an app hosting service through its Sencha.io cloud services.