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.
Related
I have a Renesas R5F571M processor that has 4MB of flash and 512K of RAM.
I need to run FreeRTOS and also have a web server that can run Lua scripts in order to interface to the hardware with custom C code.
Can anyone suggest a very compact HTTP+Lua server that I could use.
The Barracuda Application Server looks ideal but at around $20K is way out of my reach.
I would love to be able to use Nginx and PHP but the resource constraints preclude that option.
I once upon a time, worked with the Lighttpd web server. You could compile it under certain conditions to a binary as small as, ~400KB size (400KB << 4MB). On the backend you could interface it to the fastCGI C-library. The backend then you can write in C.
You can skip the Lua scripts in my opinion. Or if you still want to use them, you could use the Lighttpd mod_magnet module which can work directly with Lua, so you can skip the FastCGI library. It also has a smaller memory footprint than Nginx, although I am not sure if it is small enough to fit in the 512KB RAM.
p.s. Lighttpd is free.
on the compact side:
bozohttpd http://www.eterna.com.au/bozohttpd/ HTTP/1.x webserver that can run lua scripts but forks with every request so it's stateless in that sense
lhttpd https://github.com/danristea/lhttpd HTTP/1.x HTTP/2 webserver that was inspired by bozohttpd but integrates lua coroutines with an event system (kqueue/epoll) to achieve non-blocking stateful execution.
(disclaimer: I am the author of lhttpd)
How to make an external program control Tridium Niagara framework? I see two options; Which one is correct:
1) Niagara allows addition of 3rd party code to provide an API, and someone else has already done that and we can use it.
2) Niagara allows 3rd party code to do API but we have to write our own.
Niagara installations can be configured to process many different network control protocols driven by an external process across the network, for example by BACnet. The Niagara instance can be configured internally in many different ways to respond to control from across the network.
Niagara 4.x prominently features Web GUIs, including Javascript client widgets and server Javascript, or the server can respond to the Web GUI activity with its other configuration and scripting methods.
For any real complexity beyond the bundled network drivers or HTTP, 3rd party modules coded in Java are used. These would typically be coded as Niagara drivers, processing data over serial or sockets.
Niagara's APIs are mostly open. But Niagara is a complex environment. Completing Tridium's week-long developer training/certification is typically required to produce a proper module.
There are some external API's that Tridium built into AX. oBIX and Bajascript.
I've written external oBIX programs in both Java and Python to pull data from a remote Jace. You'll have to add the oBIX service and export the points you want to see.
Bajascript is a javascript library Tridium uses to interact with the system as well. I believe they released Bajascript 2.0 not to long ago. http://www.bajascript.com
If those don't do what you like, you'll more than likely need to write your own API to handle it.
I only have a small knowledge about Tornado, and when it comes to deployement, it is better to use Nginx as a load balancer with the number of Tornado process.
How about Twisted? is that the same way?
If I'm tracking your question right, you seem to be asking: "Should Tornado be front-ended with Nginx, how about Twisted?"
If thats really where the question is going, then its got a "it depends" answer but perhaps in a way that you might not expect. In a runtime sense, twisted, tornado and Nginx are in more ways than not the same thing.
All three of these systems use the same programming pattern in their core. Something the OO people call a Reactor pattern, which is often also known as asynchronous I/O event programming, and something that old-school unix people would call a select style event loop. (done via select / epoll / kqueue / WaitForMultipleObjects / etc)
To build up to the answer, some background:
Twisted is a Reactor based framework that was created to for writing python based asynchronous I/O projects in their most generic form. So while its extremely good for web applications (via the Twisted Web sub-module), its equally good for dealing with Serial data (via the SerialPort sub-module) or implementing a totally different networking protocol like ssh.
Twisted excels in flexibility. If you need to glue many IO types together, and particularly if you want to connect IOs to the web it is fantastic. As noted in remudada answer, it also has application tool built in (twistd).
As an async I/O framework, Twisted has very few weaknesses. As a web framework though (while it is actively continuing to evolve) it feel decidedly behind the curve particularly as compared to plugin rich frameworks like Flask, and Tornado definitely has many web conveniences over Twisted Web.
Torando is a Reactor based framework in python, that was created to for serving webpages/webapps extremely fast (basically as fast as python can be made to serve up webpages). The folks who wrote it were aiming to write a system so fast that the production code itself could be python.
The Tornado core is nearly a logically match to the core of Twisted. The core of these projects are so similar that on modern releases you can run Twisted inside of Tornado or run a Tornado port inside of Twisted.
Tornado is single-mindedly focused on serving webpages/webapps fast. In most applications it will be 20%ish faster then Twisted Web, but nowhere near as flexible as supporting other async I/O uses. It (like twisted) is still python based, so if a given webapp does too much CPU based work its performance will fall quickly.
Nginx is a Reactor based application that was created to for serving webpages and connection redirection written in C. While Twisted and Tornado use the Reactor pattern to make python go fast, Nginx takes things to next step and uses that logic in C.
When people compare Python and C they often talk about Python being 1.2 to 100 times slower. However, in the Reactor pattern (which when done right spends most of it's time in operating system) language inefficiency is minimized - as long as not too much logic happens outside of the reactor.
I don't have hard data to back this up but my expectation is that you would find the simplest "Hello world" (I.E. serving static test) running no more then 50% slower on Tornado then on Nginx (with Twisted Web being 20% slower then Tornado on average).
Differences speed of the same thing, where does that leave us?
You asked "it is better to use Nginx as a load balancer with the number of Tornado process", so to answer that I need to ask you question back.
Are you deploying in a way where its critical that you take advanced of multiple cores?
In exchange for blazing async IO speed, the Reactor pattern has a weakness:
Each Reactor can only take advantage of one process core.
As you might guess, the flip side of that weakness is that the Reactor pattern uses that core extremely efficiently and if you have the load, should be able to take that core near 100% use.
This leads back to the type of design your asking about, but the reason for all the background in this answer is because the layering of these services (Nginx in front of Tornado or Twisted) should only be done to take advantage of multi-core machines.
If your running on a single core system (lowest class cloud server or an embedded platform like a Raspberry Pi) you SHOULD NOT front-end a reactor. Doing so will simple slow the whole system down.
If you run more (heavily loaded) reactor services then CPU cores, your also going to be working against yourself.
So:
if you're deploying on single core system:
Run one instance of either a Tornado or Twisted (or Nginx alone if its static pages)
if your trying to fully exploit multiple cores
Run Nginx (or twisted) on the application port, run one instance of Tornado or Twisted for each remaining processor core.
Twisted is a good enough application server on it's own and I would rather use it as it is (unlike Tornado)
If you look at the offical guide http://twistedmatrix.com/documents/11.1.0/core/howto/application.html
you can see how it is set up. Ofcourse you can use uwsgi / nginx / emperor with twsited since it can be run as a standard application, but I would suggest that you do this when you really need the scaling and load balancing.
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.
I'm in the process of providing a Web UI as an alternative to our current desktop UI for our C/S enterprise application.
When developing the client-side in our desktop version, UI developers could connect to any server so they only needed the client-side environment.
When developing a Web UI (Client-side JavaScript in the browser), we are bound by the browser's "Same origin policy" so the UI must talk to the same server from which the UI code is downloaded.
As far as I see it till now, the development scenario for the UI guys is:
Developer installs server on local
machine and runs it.
Developer edits the HTML+JS+CSS files on local installation.
Developer has to reinstall/update server on local machine each time there's a need to test UI code against new server behaviour.
This does not seem too comfortable, at least compared to our previous C/S style development.
Are there any other ways you can suggest to that will not require UI developers from installing and updating server side components on their development machine ?
Or anything else related that can simplify the development process ?
Thanks :-)
Editing in some clarifications:
I'm mostly interested in the aspects of UI coding, not UI design.
I need a lot of server interaction - getting data from RESTful web services, which are developed in parrallel - hence the need to have an up-to-date server
You haven't specified the development platform.
As far as pure HTML/JS/CSS is concerned, you don't need a server. The UI developer can fine tune UI components locally.
The moment you want to talk/integrate to Server (via AJAX, JSP, ASP...) then you need to connect a development server as now your changes have to be served by Server.
Most of UI fine tuning can also be done from Firebug
In our office when changes to styling are required we save the page as a local copy and send it to the UI designer, he makes his changes and we integrate them. So the UI designer don't have to maintain a development environment.
JSONP lets you work around the same-origin problem (with server support) -- check it out! If the front-end-in-the-browser developers are using a good framework suc as jQuery or (my favorite) Dojo, JSONP should be no harder for them than plain JSON.
Develop on a shared server, but depending on the size of the team.. that's challeging with respect to version control.
Or deploy automatically generated virtual machines with nightly builds, so the devs don't have to install, but always use a recent version.
In the case of UI developers depending on a common REST server, the UI development can be done on the local machine and the REST service should be on a central server. When changes are made to the REST service these should be deployed to the central server (when stable), so all developers can use the newest version (this also helps with testdata).
You could try using a proxy on the developer's machine where some paths redirect to the server and some paths redirect to local folders.
Hmm, I actually didn't really get any information on what kind of technology you're using. If - with UI Developers - you mean designers, which have to take care about the CSS, layout etc, then we do it the same as lud0h said. We (developers) send the UI designers a copy of the server-side produced HTML pages. They then edit the HTML pages according to accessibility guidelines, CSS and layout and send us back the outcome of their work. We use their HTML pages then for integrating them in our web applications.
If you don't just mean tuning CSS, but also to write JavaScript / Ajax functionality you HAVE to use a server with which you're communicating. As you said, normally this is done by having a local environment which is similar to the server-one. In .Net Visual Studio '08 provides an internal webserver, alternatively you have to install IIS locally. In Java environments you have to install Tomcat and related technologies. In my eyes this is a must. What you have to have is
Versioning system (CVS, SVN,...) where developers commit regularly (minutes/hours)
local environments where developers checkout the source from the repository and develop
Test server where you deploy on a daily basis (could be like daily builds) in order to test your running product
I guess this should be what a professional development environment should consist of. The difference to C/S application development is that web UI and web-client code are not that separable as a Client UI in C/S environment from the server-side. Unless you develop with technologies like GWT or Silverlight which are quite similar to C/S, just running inside the browser, but communicating over RPC calls or web services.
//Edit:
What I nearly forgot. Don't do something like developing on the server directly, meaning that all of the developers access the server's filesystem where the code, UI etc. lies!!
You can use CORS. a new technique just like Ajax, but with ability to make calls on other domains. so you will need only one UI on one server. think this can help you.