What Server-Side Web Technology Should I Use in an Embedded System

What server-side web technology should I use in an embedded system?

Some of the later versions of OpenWRT come with an interface written entirely in lua (LuCi). Have you checked this out to see if it applies? It runs over standard CGI and is called by the embedded web server that is already running on the OpenWRT (meaning you don't have to add yet another software package).

Check out their website luci.freifunk-halle.net, it apparently is a full featured web framework including MVC, so you are able to get started faster!

LuCI is a collection of free Lua software for embedded devices. It includes several useful tools and libraries for developers as well as an MVC-Webframework and web user interface which is part of OpenWrt Kamikaze starting from release 8.09. The goal of the LuCI Project is to create and maintain user friendly, stable and reliable user interfaces and development frameworks.

PHP is rather big for a router, and I think it won't quite provide the speed that you are looking for! Lua is not a hard scripting language to pick up and start with, it is not that different from PHP, and the Lua website is very good and has loads of documentation!

Web technologies for an embedded server

When I was in this area, I used Lua and a simple FastCGI runner (Luaetta [for I'm sure the latest source would be available if you asked the guy] , though I'm also sure that's not the only one, and there's Kepler of course), spawned by lighttpd.

It performed quite well on an embedded media player, and was used for remotely accessing content and controlling the device. Though I don't maintain it anymore, you can find more about it at http://matthewwild.co.uk/projects/wooble . If you think the source would help just poke me for it, it's currently only available via a package manager but I can fix that given the motivation.

Another (again Lua) project in this area is LuCI. These guys are dedicated to making a web interface for embedded devices (routers specifically), and have produced a nice framework with lots of supporting libraries geared towards that kind of system.

I wouldn't be concerned with not knowing Lua. If you know any language then you can pick up Lua in a day or two, the manual documents the whole language and is quite short.

Server-Side Web Framework to use for an Embedded Device

Justin,
It sounds like your platform has relatively a lot of horsepower. For this reason, I'd say go with the framework you're most comfortable with. PHP and mod_perl are plenty fast and efficient. It really depends on what modules are available for the http server that you're running.

Your question led me to take a peek at the framework that tomato firmware uses for their web interface. Their server is micro_httpd/mini_httpd with cgi extensions, and the pages are asp. There is also some javascript thrown in. Here's a link to tomato firmware where you can download the source and have a look for yourself. If your device is similar to a wireless router, you should check out other router firmware projects, such as dd-wrt, openWRT, and sveasoft.

Mateja

Server and client side programming language and frameworks to use in embedded systems

You could use an HTTP server library like Onion (in C), GNU libmicrohttpd (in C), or Wt (in C++) to make your own specialized HTTP server (embedded inside your device).

You could also use Ocsigen in Ocaml for the same purpose.

I don't think that embarking a complete HTTP server (apache, or perhaps better lighttpd) with a PHP stack makes real sense on an embedded device (the code stack would be much bigger). On such a device the performance does not matter much (you won't get thousands of HTTP requests per second), but the code space (and process space, ie memory consumption) is quite important. (And the specialized web server solution I am suggesting uses only compiled code, which would run faster than interpreted PHP).

If you insist on having a lighttpd or apache web server in your device -which I believe is wrong-, you could make your application a FastCGI application (and code it in C, C++, Ocaml, ...).

As Simon Richter commented, you could consider making it (also) an SNMP service.

Designing Web Interface for Embedded System

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

Web Interface for embedded system

Similar projects in which I have worked tend to use Python with either web.py or bottlepy.org. They are simple to deploy and maintain and very light. If your project is simple, that is, you only need to build a minimal web, then I'd go for web.py, whereas if you need something more sophisticated bottlepy is better.

Embedded web server with integrated XML parser

When it comes to a simple python server stack, the combination I've heard most often from within the community for lightweight implementation is CherryPy (to provide the thread-pooled WSGI server) with Werkzeug (to create the basic structure of the app) Both are very slightly different takes on WSGI that speed development time considerably.

There some pretty good notes outlining basic python framework comparisons (albeit not in an embedded environment, but the emphasis was on lightweight deployments.) at this question, in which Alex "the Machine" Martelli weighed in for these two.

If you can afford the overhead of the python interpreter (which I am assuming is ok as you included it in your eligible list), werkzeug is an excellent way to setup an app that consists of simple endpoints. Responses can be mimetyped inline to aid in outputing your UI libs (Jquery, etc). There are awesome examples on the Werkzeug docs.

One of the best resources I've been able to find on comparing WSGI servers (to satisfy your need for high concurrent connections and DOS survivability) can be found at Nicholas Piel's blog post on the subject, where CherryPy ranks in as one of the best "bang-for-your-buck" resources to speed-wise. The WSGI server in Cherry is deployment ready, and this can be used as the server process providing the environ to your Werkzeug app so you don't need to implement something heavier like Apache with mod_wsgi. Cherry is easily capable of an average around 2000 r/ps with response times well under a second while under moderate load.

Since I don't know what kind of device you will be deploying this on, I should mention of course that both of these platforms are regularly updated, so this too should be considered if for whatever reason allocating network resources to update the device is impractical.

By combining python's minidom module (v2.6+) with the endpoint routing in Werkzeug, you should also benefit from very good development speed. Constructing a complex url schema is simple using Werkzeug's Map feature, and the tutorial at their documentation page gives an awesome rundown on this. Between the two, it shouldn't be too difficult to get your web service up and running.

What .NET server-side technology can be used with an AngularJS app?

To me it seems like you are trying to make a Single Page Application. I understand your confusion with routing, so I will explain how we do it.

We have a ASP.NET MVC5 project that also hosts ASP.NET Web API 2. All of our MVC5 routes are being handled by single action in a single controller:

routes.MapRoute("CatchAll", "{*url}",
                    new { controller = "Home", action = "Index" }
                        );

This action returns a view and this view is the basic HTML that we need to make the AngularJS application work. This HTML contains in the head the CSS and JavaScript files needed (frameworks and application logic like controllers, directives, services etc) and in the body it contains some basic HTML like the header, footer and the ng-view element where views for each route that you map are rendered.

Now, with the ASP.NET Web API we implement our REST web services that are consumed by the AngularJS application. These web services are returning JSON objects that are well understood by AngularJS and you will use them in your JavaScript application without any friction.

To conclude, any link that you will hit in your browser, like /Home/Index, /Home/Friends, /Account/Settings etc, the server will always return the same HTML and AngularJS will read the URL and will execute the appropriate controller and appropriate view that you have configured in your application.

To read more about Single Page Application: http://en.wikipedia.org/wiki/Single-page_application

To read more about Single Page Applications using AngularJS: http://scotch.io/tutorials/javascript/single-page-apps-with-angularjs-routing-and-templating2

To read more about REST services: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

---

This is not the end of the story though. I said that any route that you hit, the server will always return the same HTML. Then why use ASP.NET MVC5? This basic HTML can be a static file, right?

Well, this concept will not work when it comes to Search Engine Optimization. Search engines bots are not executing JavaScript, so they expect that all that they need is served with that single hit on your route (link). Also, Facebook does not execute JavaScript, but also expects HTML specific to the page that the user is trying to share.

So, what we did is we created the same routing on the server side as the one mapped on AngularJS and added a filter to each action. This filter checks if the request is being made from a browser, it returns the same HTML for every action. If it is a request from Google or Bing bot, or Facebook scraper, then the filter allows execution of the action and the action returns appropriate HTML for that route. This HTML is very basic, structured really well to be understood by Google, Bind and Facebook and does not include any CSS or JavaScript.

---

Related Topics