Lots of languages have microframeworks for writing very tiny websites or web services, such as Flask for Python, or Sinatra for Ruby. On Squeak, there doesn't seem to be any equivalent; Iliad, Seaside, and AIDA are all very heavy for just having a little service. What's the preferred way to accomplish this? Directly injecting a hanlder into Comanche or Swazoo?
"In this particular case, I literally have three URLs that need to do stuff via HTTP POST; that's it."
For really simple cases, you can just register with (or subclass) Kom's HttpService like so (from the class comment, see for more info/options):
(HttpService on: 8080 named: 'Example Http Service')
onRequestDo: [ :httpRequest | SomeGlobal processRequest: httpRequest ];
start
You can also use teapot. Teapot is micro web framework on top of the Zinc HTTP components, that focuses on simplicity and ease of use. It's under 500 lines of code, not counting the tests.
Teapot on
GET: '/hi' -> 'Bonjour!';
GET: '/hi/<user>' -> [:req | 'Hello ', (req at: #user)];
GET: '/say/hi/*' -> (Send message: #greet: to: greeter);
start.
(ZnEasy get: 'http://localhost:1701/hi/user1') entity string. "Hello user1"
There are available mustache templates, output transformers, before filters. The framework is well documented.
I would like to share what I think is more up-to-date information (as of end of 2012).
Zinc Components
Currently in Pharo 1.4/2.0 the de-facto standard for HTTP client/server seems to be the Zinc HTTP Components. And the latest Seaside version (3.0) switched to Zinc as well.
You can of course use Zinc directly to implement web-services or serve web-pages.
Take a look particularly at classes ZnServer and search for classes like Zn*Delegate (like ZnDefaultServerDelegate or ZnStaticFileServerDelegate)
Seaside REST
Latest versions of Seaside include support for RESTful web-services. This can be used to implement web-services or serve web-pages. It's pretty straightforward.
For more information look at the "REST Services" chapter of the online Seaside book. This chapter centers about implementing web-services, but it works for web-pages as well.
Ratpack
I have also been told about Ratpack, a sinatra-like web-framework developed by Tim Felgentreff. There are two repositories. I think the github one is more recent. See here:
http://ss3.gemstone.com/ss/RatPack.html
https://github.com/timfel/ratpack
This information comes from a similar question I posted recently.
You can subclass a SwazooSite in Swazoo for such a micro website, but I think you will soon end needing more functionality, so starting directly on one of those three frameworks are better bet long-term.
That they are heavy is maybe just an impression and lack of better documentation of usage for such simple websites. Also, if you look at the framework as blackbox, which is complex internally but simple externally, then I'd say all Smalltalk web frameworks are quite simple comparing to other web frameworks.
Related
I am building a server-client application that involves heavy signal processing (e.g. FFT). I have a working application written in C++/Qt, where everything (signal processing and other calculations) is done in client and server just sends raw data. Now I feel it would be easier to implement these features on the server. So, that maintenance becomes easier.
As I am doing signal processing, I think I should stick to C++ for performance. But I am open to new ideas.
Constraints:
I need type checking so javascript is out of discussion.
Scaling includes adding more server and each server will have at the max
10-12 users. So, Hardware cost is important. I cannot use x number of
i7 processors.
No option of using cloud services.
So, right now my question is as follows:
How can I create web services using C++ for Linux server? (Although cross platform is not important, I would appreciate if I can achieve it.)
EDIT [02:09:2015]
Right now, I think the choice is between poco and C++ Rest SDK. I feel I should go for C++ Rest SDK. Mainly because it has only those features that I need. And Also it is supported by microsoft and uses boost internally. So, I feel in future, this might be well integreated with standard.
You could use cross-platform Poco library to implement HTTP server, it is really straightforward with this framework, and they have a lot of examples. You can also use JSON serialization (like rapidjson library) to implement REST service on top of HTTP - this way your Web service will be accesable by most of the modern Web frameworks.
You might want to take a look at the C++ Rest SDK, an open source, cross platform API from Microsoft.
Like #nogard suggested, I also recommend POCO for now. It's the most serious and feature-full solution. Given you mentioned Qt, I suggest you to take a look at Tufão.
EDIT:
I forgot to mention one comparison of mine on the C++ HTTP server frameworks.
If you directly handle HTTP requests, you might loose the functionality what Web Servers does well what it was build to do. I had a similar issue, what I did was wrap up my Qt c++ code inside a PHP extension. In your case you can do the same. Wrap your logic inside what ever technology you are about to use, doesn't matter it's PHP, net , Java or anything else.
Going to start a new Web app in Clojure, going to use the following libraries as a base to start with but would like to hear of others instead or in addition:
Om - UI
Secretary - Client side navigation (replace with Bidi or Silk?)
Sente - Client/Server communication
Ring/Compojure/HttpKit - Web server
Component - Application architecture/modularity/reloaded pattern (Something else here?)
Friend - Authentication/Authorization (Buddy instead?)
Liberator - REST web services (Any alternative?)
Figwheel, Weasel, Reloaded Pattern - Development sugar
This answer really depends on what you actually need. There's no such thing as an overall combination of libraries that you should always use as a starting point for a project. You haven't specified your requirements, so we can't say what you should put into your project.
Here are some general observations:
Many Om apps are single-page apps, loaded from a single URL. If that's your case as well, you don't need Secretary. If you have multiple URLs all using the same compiled clojurescript file, then that's where Secretary comes into the picture. But if you are not using :advanced optimizations with clojurescript, then you also don't need Secretary since you can explicitly load a particular namespace on each page. Depends on the level of complexity and deployment you are desiring.
You mention Http Kit, do you have specific needs for that over Jetty, which tends to be much more common? If it is because you want websockets, it is worth considering why you need websockets. They are cool but should be given consideration before adopting them as your default environment, in my opinion. Websockets are certainly not without their flaws, and most cases of server-browser communication are handled very easily, simply and in a more stable manner by using normal request/response and ajax, which has been around much longer and is something worth knowing and using, even if you later decide websockets are worthy of exploration. I would recommend cljs-ajax library for that purpose.
You should add the fogus EDN library to your list, since it is Ring middleware that will handle data transfer between browser and client regardless of your preferred transport method.
Your choice for an authorization library really depends on the type of authorization you need. There isn't a one-size-fits-all in that area.
Note: I'm a backend (Java) developer by trade and work in Clojure in my spare time, so forgive me for my ignorance.
I'm trying to get my head around Clojurescript and how it could potentially fit in with projects I'm working on, or plan to work on in the future. As I've grown up with the "classic" web development mindset (e.g. Clojure running the backend, distributing data to the frontend via JSON to be processed in JS or returning a HTML page for the browser to render), I'm having trouble trying to understand how Clojurescript might make things better than this model.
Could anyone explain to me what the general approach to Clojurescript/Clojure development would be, seeing as the "Clojurescript One" project moniker signifies that application development will be unified under one language (as such)
What tasks would normally be done in the Clojurescript portion of the application?
What tasks would normally be done in the Clojure (e.g. backend) portion of the application?
Any help would be appreciated, or if anyone can point me towards some diagrams or explanations or anything - that would be great too!
I think Clojure/ClojureScript applications will be structured very similarly to X backend technology + JavaScript.
One big benefit with architecting applications with Clojure and ClojureScript - a richer data format than JSON (you can represent hash-maps and sets with arbitrary keys) without losing compactness.
JavaScript is a fine, fine language but ClojureScript offers quite a few benefits. It's semantically simpler (functional), ships with a rich standard library, a robust battle tested application library (Google Closure), and all the benefits you get from the tasteful application of syntactic abstraction via macros.
That said, it's still very much alpha software and the tooling still needs a lot of work.
A bit of background about me, I have developed with Clojurescript, JQuery, Vaadin, Servlets, JSP, and many other web technologies.
1) Clojurescript is much harder to learn than any other web technology I have used as you need, Java, Clojure, Closure (with an s ;), Closure Lib, and Closurescript specific knowledge.
2) Clojurescript doesn't make sense for a small app. It only makes sense when you will have ALOT of client side processing
3) Clojurescript's only use as far as I see is as a better javascript (which is why it is better suited to larger apps) as the minifier part of Clojurescript is available for javascript too
4) Only the client end would be written in Javascript, the server would be in Clojure/Java servlets
Maybe Ganelon micro-framework (which incidentally I am author of) will suit your needs - the execution model is similiar to Vaadin's: server-side Clojure code pushes UI updates to the browser through AJAX/JavaScript, but we don't store application state in session by default.
The demo and docs are available at http://ganelon.tomeklipski.com/
For me, clojure and clojurescript offers cleaner code than mixed stack. There is only one language to think of and code is quite easy to read.
At the backend clojure does things that java usually would do. Input validation, saving to database and above all, implementing business logic. Our backend also validates incoming / outgoing data by types using prismatic schemas.
Frontend in short: We get pretty code using ClojureScript and it is fast to write. We are using ClojureScript version of material-ui when writing UI components. We have to write less code when compared to the JavaScript and I find our UI component code to be easier to read than JavaScript counterpart. One of the main reasons is shorter closing tags and less noise by coding language. Development with ClojureScript is quite fast.
Of course ClojureScript is used for simple imput validation like RegExp for phone numbers etc.
One of the disadvantages of clojure which you have probably noticed is long lines after giving proper names to the functions. I havent found silver bullet how to cope with that.
As dnolen said: ClojureScript is still developing. It is way better now than it was 6 months ago, so you'll have to keep checking its maturity now and then.
Background:
I have a new site in the design phase and am considering using ColdFusion. The Server is currently set-up with ColdFusion and Python (done for me).
It is my choice on what to use and ColdFusion seems intriguing with the tag concept. Having developed sites in PHP and Python the idea of using a new tool seems fun but I want to make sure it is as easy to use as my other two choices with things like URL beautification and scalability.
Are there any common problems with using ColdFusion in regards to scalability and speed of development?
My other choice is to use Python with WebPy or Django.
ColdFusion 9 with a good framework like Sean Cornfeld's FW/1 has plenty of performance and all the functionality of any modern web server development language. It has some great integration features like exchange server support and excel / pdf support out of the box.
Like all tools it may or may not be the right one for you but the gotchas in terms of scalability will usually be with your code, rarely the platform.
Liberally use memcached or the built in ehache in CF9, be smart about your data access strategy, intelligently chunk returned data and you will be fine performance wise.
My approach with CF lately involves using jQuery extensively for client side logic and using CF for the initial page setup and ajax calls to fill tables. That dramatically cuts down on CF specific code and forces nice logic separation. Plus it cuts the dependency on any one platform (aside from the excellent jQuery library).
To specifically answer your question, if you read the [coldfusion] tags here you will see questions are rarely on speed or scalability, it scales fine. A lot of the questions seem to be on places where CF is a fairly thin layer on another tool like Apache Axis (web services) and ExtJs (cfajax) - neither of which you need to use. You will probably need mod-rewrite or IIS rewrite to hide .cfm
Since you have both ColdFusion and Python available to you already, I would carefully consider exactly what it is you're trying to accomplish.
Do you need a gradual learning curve, newbie-friendly language (easy for someone who knows HTML to learn), great documentation, and lots of features that make normally difficult tasks easy? That sounds like a job for ColdFusion.
That said, once you get the basics of ColdFusion down, it's easy to transition into an Object Oriented approach (as others have noted, there are a plethora of MVC frameworks available: FW/1, ColdBox, Fusebox, Model-Glue, Mach-ii, Lightfront, and the list goes on...), and there are also dependency management (DI/IoC) frameworks (my favorite of which is ColdSpring, modeled after Java's Spring framework), and the ability to do Aspect-Oriented Programming, as well. Lastly, there are also several ORM frameworks (Transfer, Reactor, and DataFaucet, if you're using CF8 or earlier, or add Hibernate to the list in CF9+).
ColdFusion also plays nicely with just about everything else out there. It can load and use .Net assemblies, provides native access to Java classes, and makes creating and/or consuming web services (particularly SOAP, but REST is possible) a piece of cake. (I think it even does com/corba, if you feel like using tech from 1991...)
Unfortunately, I've got no experience with Python, so I can't speak to its strengths. Perhaps a Python developer can shed some light there.
As for url rewrting, (again, as others have noted) that's not really done in the language (though you can fudge it); to get a really nice looking URL you really need either mod_rewrite (which can be done without .htaccess, instead the rules would go into your Apache VHosts config file), or with one of the IIS URL Rewriting products.
The "fudging" I alluded to would be a url like: http://example.com/index.cfm/section/action/?search=foo -- the ".cfm" is in the URL so that the request gets handed from the web server (Apache/IIS) to the Application Server (ColdFusion). To get rid of the ".cfm" in the URL, you really do have to use a URL rewriting tool; there's no way around it.
From two years working with CF, for me the biggest gotchas are:
If you're mainly coding using tags (rather than CFScript) and formatting for readability, be prepared for your output to be filled with whitespace. Unlike other scripting languages, the whitespace between statements are actually sent to the client - so if you're looping over something 100 times and outputting the result, all the linebreaks and tabs in the loop source code will appear 100 times. There are ways around this but it's been a while - I'm sure someone on SO has asked the question before, so a quick search will give you your solution.
Related to the whitespace problem, if you're writing a script to be used with AJAX or Flash and you're trying to send xml; even a single space before the DTD can break some of the more fussy parsing engines (jQuery used to fall over like this - I don't know if it still does and flash was a nightmare). When I first did this I spent hours trying to figure out why what looked like well formed XML was causing my script to die.
The later versions aren't so bad, but I was also working on legacy systems where even quite basic functionality was lacking. Quite often you'll find you need to go hunting for a COM or Java library to do the job for you. Again, though, this is in the earlier versions.
CFAJAX was a heavy, cumbersome beast last time I checked - so don't bother, roll your own.
Other than that, I found CF to be a fun language to work with - it has its idiosyncracies like everything else, but by and large it was mostly headache free and fast to work with.
Hope this helps :)
Cheers
Iain
EDIT: Oh, and for reasons best known to Adobe, if you're running the trial version you'll get a lovely fat HTML comment before all of your output - regardless of whether or not you're actually outputting HTML. And yes, because the comment appears before your DTD, be prepared for some browsers (not looking at any one in particular!) to render it like crap. Again - perhaps they've rethought this in the new version...
EDIT#2: You also mentioned URL Rewriting - where I used to work we did this all the time - no problems. If you're running on Apache, use mod_rewrite, if you're running on IIS buy ISAPI Rewrite 3.
do yourself the favor and check out the CFWheels project. it has the url rewriting support and routes that you're looking for. also as a full stack mvc framework, it comes with it's own orm.
It's been a few years, so my information may be a little out of date, but in my experience:
Pros:
Coldfusion is easy to learn, and quick to get something up and running end-to-end.
Cons:
As with many server-side scripting languages, there is no real separation between persistence logic, business logic, and presentation. All of these are typically interwoven throughout a typical Coldfusion source file. This can mean a lot more work if you want to make changes to the database schema of a mature application, for example.
There are some disciplines that can be followed to make things a little more maintainable; "Fusebox" was one. There may be others.
I know that some big players have embraced it and are actually exposing some of their services in APP compliant way, already. However, I haven't found many other (smaller) players in this field. Do you know any web application/service that uses APP as its public API protocol? What is your own take on AtomPub? Do you have any practical experiences using it? What are its limitations and drawbacks? Do you prefer AtomPub as your REST style or do you have some other favourite one? And why?
I know, these are many questions, not just one. The thing I'm interested here in is simple, though - how did the APP standard hit the market and particularly how does it seem with its adoption among web developers?
The company that I work for, is developing a lot of RESTful services.
However none of them expose public APIs.(In the sense that all services are internally consumed by our own clients). The reason why we went for REST architectural style was that we wanted our services to be easily consumable and more importantly scale well.
From my own practical experience I have come to the conclusion that HTTP + ATOM syndication format is a good idea, provided you want to keep things flexible(In terms of different content model, attaching and extending meta data associated with payloads, uniform parsing etc). ATOM ensures that everybody interprets the payload in an uniform manner without any scope for ambiguity.
However if one does not have any such complex requirements or does not forsee such requirements then the ATOM format could be a bit of an overhead. (For instance elements like Author,Title etc make sense more in the blogging/RSS world and may not make sense in your particular problem domain).
Also if the goal is to just serialize data structures at one end and reconstruct it at the other end, then most web frameworks(like WCF) have custom formats which are more appealing.
So in my opinion ATOM Pub is good if you need flexiblity in terms of data representation and if the playing field is huge with different kind of client.
However if you have a good knowledge of potential clients and server/client usage patterns then custom formats might be a good idea.
If the client is browser based then formats like JSON are very appealing.
Hope this answers your question.
My own research so far:
Wordpress supports AtomPub as its API protocol since version 2.3
GData is probably the biggest shot in the AtomPub field so far
Habari - new promising blogging system promotes APP as one of its main features
BlogSvc.net - an AtomPub
server, blog engine for .NET
platform, written in C#
Jangle - an open source project
designed to facilitate API access to
Library Systems
There's also mod_atom - an Apache module that stores entries in the filesystem.
Last time I checked (2007 or so) Atompub was fairly complex to implement. While you can whip together something that emits valid Atom feeds during the lunch break, implementing AtomPub was a fairly big undertaking.
That might have changed due to better libraries and tools but still it might be too complex to be implemented by smaller sides just because it's cool.
And the lack of killer AtomPub client applications puts little or no pressure on server operators to offer an AtomPub interface.