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.
Related
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'm just starting with distributed application development. I need to create (all by myself) an enterprise application for document management. That application will run on an intranet (within the firewall, no internet access is required now, BUT is probably that will be later).
The application needs to manage images that will be stored within MySQL Server (as blobs) and those images will be then recovered by the app and eventually one or more of them will be converted to PDF.
Performance is the most important non-functional requirement.
I have a couple of doubts.
What do you suggest to use, .NET Remoting or WCF over TCP-IP (I think second one is the best for the moment I need to expose the business logic over internet, changing the protocol).
Where do you suggest to make the transformation of the images to pdf files, I'm using iText. (I have thought to have the business logic stored within the IIS and exposed via WCF, and that business logic to be responsible of getting the images and transforming them to PDF, that because the IIS and the MySQL Server are the same physical machine). I ask about where to do the transformation because the app must be accessible from multiple devices, and for example, for mobile devices, the pdf maybe is not necessary.
Thank you very much in advance.
WCF, only consider remoting if WCF presents some issue such as performance in your use case. You have many many more scaling and customisation options available under WCF.
Depends. If sending the images over the net presents an issue then it may have to be done locally. However as in (1) your existing suggestion seems ok.
See .Net Remoting vs. WCF for a similar question.
Definitely remoting if this is an option
Transformation - same box that the service is; since the service is going to funnel the images anyway - this is the best place. I would not put it on DB server, to better distribute the load and to separate non-db load from db specific load.
In addition, look into .Net 4.0 RIA services. They allow you best combo of .Net Remoting and WCF
Is Mono appropriate for developing server applications, or only desktop applications? I'd like to develop server applications in C# for Linux. I want to write a First Person Shooter (FPS) game in C#/XNA, and I've a Linux dedicated server. But this question is generally for all types of server applications...
Mono handles ASP.NET (including ASP.NET MVC) quite well. Most other server implementations work very well, as well. It does depend, slightly, on what exactly you are trying to serve, and how you are going to use it.
Mono also supports WCF directly in the core, which allows most non-web service applications to be written very effectively.
Edit:
Given your edit, and your desire to handle the server side of a multi-player FPS game, Mono should work fine. You will likely want to avoid using the high level interfaces like WCF and ASP.NET, and go straight to the System.Net namespace (depends a bit on how many players you'll be synchronizing, but if it's large, you'll want speed here over ease). Mono supports this quite well.
That being said, Mono's support of the System.Net namespace is very good, and quite mature, so you should have no problems using it for the server side of a multiplayer FPS game.
I don't see why not. I believe FogBugz uses Mono to deploy to apache servers.
Here is a conversation about running the FogBugz application on mono as an example of having a server app running on it.
It looks like your needs cover a broad range of different applications.
I think the overall answer would be yes, Mono is appropriate for developer server applications.
As others have pointed out, Mono has ASP.NET support as well as WCF built-in.
You also have the ability of working directly down to the Socket level if you need to squeeze every last bit of performance out of your server application (although you'll have to figure out how to persist state if the need is there).
I'd definitely be interested in seeing the performance difference of something like that between the two platforms (I wouldn't expect much difference...it's possible that Mono might even get slightly better performance because of the rest of the *NIX stack).
OS : Linux.
I'm trying to find possible ways to implement web interface for my embedded system.
Currently there is a shell (text based) and a small set of commands are implemented to query the device.
I'm new to web development, my questions are:
What web server must I use? (I got apache up on my development setup and tried using CGI to fetch some pages, but seems like this not the right choice for embedded systems)
Assuming I'm using CGI, what strategy can be used for passing data between CGI and the Main App?
I intended to create a thread in the MainApp to handle the query from CGI script. This thread would call interfaces in the MainApp, retrive the data and pass it to CGI.
We use Lighttpd on our embedded systems, it's small and very easy to integrate. There are also specialized webservers with features especially geared to embedding, like AppWeb, which in my opinion is also a very nice product.
For the communication between the main application and the CGI's you can use sockets, or System V message queues if those are available on your embedded platform. The advantage of SYSV message queues is that they're very easy to use and manage, and messages in the queues survive restarts of the applications, but they also have some quirks (like you can't select() on them).
As web server another choice is thttpd. I use it successfully in an industrial product.
For the communication between CGI and main application sockets is the right choice.
There is no web server you must use, but there are some better choices for embedded than apache. Apache is designed for embedded and is bigger and slower.
I would not recommend CGI. It is slow to run and slow to develop. I can speak for Appweb for which I'm one of the developers. Appweb has two good web frameworks:
Ejscript which is a server-side Javascript framework for Appweb
ESP which is an MVC C-Language web farmework
ESP is extremely fast and provides easy binding of controllers to URLs. Ejscript is bigger and has a more extensive class library. Both are designed for embedded. Both are much better than CGI and execute 20+ times faster than CGI.
I am working in LuCI, which is a light CGI for embedded device. Actually it is for openwrt which is a open source project of wireless router.
The server is uhttpd , light and powerful.
The CGI script is Lua whose interpreter is no more than 10k, delicate, right? And it is developed by C and can communicate with C, powerful.
So this is my suggest.
We use JUCI with openwrt. It is written in javascript that runs on the client browser and communicates with web server over json rest api. The backend can be implemented in any language but we use reusable components written in C that plug into system bus (ubus). This means that relevant services expose their functionality through ubus which can both be used through cli and through rest api. It's actually pretty nice.