A few days back I ran a survey on Survey Monkey asking:
A client has a rusty-old SOAP API written in CFML which needs overhauling. We possibly have the opportunity to rewrite it. The rest of the codebase is CFML, and the team's strengths lie in CFML and C#, with passable clientside JS. This survey is soliciting community advice as to which language we should considerfor this implementation.
Note: for the purposes of this survey, the existing skill set is a reasonable consideration, but not necessarily the only one.
I've had 54 responses for it, so I'll call time on the responses and summarise them here.
The bottom line is:
| Option | %age | Votes |
|---|---|---|
| CFML | 53.70% | 29 |
| Node.js | 22.22% | 12 |
| Groovy | 1.85% | 1 |
| Clojure | 0.00% | 0 |
| Scala | 0.00% | 0 |
| Ruby | 1.85% | 1 |
| Python | 1.85% | 1 |
| C# | 9.26% | 5 |
| Other (please specify) | 9.26% | 5 |
The "Other" options were:
- Golang
- CFScript
- Doesn't matter
- C# utilising the ASP.NET Web API
- It depends
So I'll consider the CFScript a vote for CFML (CFScript is part of CFML!), and the C# one as a vote for... well... C#.
But the voting was clear: the majority of people voted to stick with CFML. I see where people are coming from, but personally (I voted for node.js), I'd see this as a chance to learn something new. People - in their comments - did observe that implementing something from scratch in a new language might not be a great idea, which is fair enough.
I'll reproduce the comments too, and comment when I have something to say.
taffy.io
CFML is established and well rounded not the language of the month..Yeah, but it's also kinda the language not even of last month, but of last decade. This is one of my considerations too... we've got a chance to move away from CFML here, and I think this is a good thing. My chief reason for not voting for C# is that I am seriously not convinced that it's a good solution for web-oriented requirements.
Works. I know how.(re ColdFusion)
Unless you are actively interesting in switching to another language to broaden your skills then its a case of what can you do in language X that Y cannot do. Since these are all equally capable of implementing a REST api (granted some might be nicer than others) so stick with what you know.
Team's strength is in CFML. Learning a new skill and being able to apply best practices as well as complete a rewrite is a lot to ask of anyone. Sure, it can be done, but more likely, security holes could exist, or things might be done in the most efficient manner. For example, when you first learned CF, you probably didn't use cfqueryparam. Now, while I would hope by now people know that you need to parameterize variables in queries in any language, I think it serves as an example of things you might not be aware of in other platforms that might require extra effort.Very good point. We've got a capable team, and we would be able to write a good solution in any language (within reason). Also we're not talking about the systems for the ISS, it's just a REST API, so it doesn't need to be perfect in its first iteration. It needs to be secure but security concerns are at a level outside the language being used, I think.
Existing CFML code base and we didn't need "Full and Strict" REST so FW/1 was more than enough for our purpose at the moment and with the route support built in, it would be very easy to go with a different implementation later and no one would be any wiser to it.
Because I'm a CFML developer and don't have much experience of the other languages. I've been playing around with Taffy recently and created a simple application (https://github.com/simonbingham/angularjs-todo/tree/develop) which may be of interest to you.Cheers Simon. I'm definitely interested in Taffy (more so after all the mention of it here), and I'll look at your code.
The speed alone is staggering. Majority of the cloud providers out there are slowly changing their APIs from Python to Golang because of the performance. You guys have C# experience, it honestly shouldn't take you much to get up to speed with Golang. Otherwise, if there's no time to learn and play, then stick with CFML.This makes me interested in Golang. I have never even seen a "G'day World" example. That said... I don't think speed is a consideration here, as it's just a REST API and is a fairly "thin" component of the overall operation (the HTTP request, and the underlying DB operations to fulfil the request).
COZ ITS COOoooLYeah. Cheers for that. This was in reference to Ruby, btw.
With CF experience already available and Taffy providing a good framework- this would be my choice..
The combination of node, HAPI and Swagger makes API development, testing, documentation and maintenance very easy[Adam notes down all the buzzwords for later research]
I would use CFML with Taffy.io framework. Mainly because of the given skill set and to not expand complexity by adding another language. If I would built a system from scratch I would consider Node.js, Groovy, Scala, Java, Ruby and Python. Does this help? ;-)Yeah. Cheers for that. ;-)
ColdBox makes this easy I've heard though I haven't tried it.
ColdBox framework. Really simple and clear.ColdBox for a REST API is way way way overkill.
The team's strengths are CFML so why stray.. . CFML is perfectly capable of handling rest. Need help, how about Taffy or FW/1
When playing around with rest api's I have been thoroughly impressed with a framework called sails.js for the node platform, coming from coldfusion and being able to choose my specific template engine along with the orm style building of the models helped with that decision.
No reason to change the language, Taffy or Railo Rest services should work fineI don't see it as needing a "reason". I see it as an "opportunity".
Nodejs is the right tool for the job when it comes to REST API. I use the actionhero node module and it's really convienient. Moreover, json serialization is faster in nodejs vs CFML.
The learning curve is very low and the language very expressive. Frameworks like Bottle or Flask are designed to write REST APIs.This was in reference to Python.
"The rest of the codebase is CFML, and the team's strengths lie in CFML..." I would def push for using Taffy then. It's an excellent REST framework. Easy to get started and dive right in.
I would develop it in Node.js. It is extremely lightweight, can run on any platform, has huge momentum and has seemingly unlimited resources (read: developers, modules, hosting, etc...). The fact that your JS skillsets are "passable" will actually lend to ramping up on the platform, and will in turn improve your overall client-side JS skills - Win-Win ( Win ). JS, like it or not, will outlive all said languages. My second choice, if given a second choice, would actually be CFML, but not Adobe CF. I'd use Taffy/Railo. This would probably take a 10th of the time to write your API than in node.js, so if time was a huge factor I'd go that route. Going C# is like putting all your eggs -uncooked- in one basket, hiding it under your house in the middle of summer, then paying a contractor to remove and mask the smell on a monthly basis. The rest of your options would require a huge ramp up cost and for not much (if any) gain.Cheers for the very thorough response! All good food for thought. I like your C# analogy too ;-)
A REST API is ideally such a thin layer that a primary concern is that you can easily leverage the rest of your codebase. That's CFML, so CFML makes sense for the REST API. Plus i don't know the C# ecosystem well enough to know if it has compelling alternative.Here's another reason why I think this situation is an opportunity to introduce ourselves to a new language: you're dead right... a REST API is very thin, so there's not actually that much work to undertake anyhow. Any REST API I write would be as thin as possible, simply being a marshalling tier between the HTTP request and the code that does the actual work.
While I am not always quick to recommend using a framework I will make the exception that they not write it but use Taffy instead. I have found Taffy to be pretty darn flexible for a wide use of business REST cases. There are two things Taffy lacks: No integration with docs such as Swagger. Internally that's not that big a deal but if it is a public API then having great docs with code samples in different languages becomes important. Does not include OAuth with the framework. If it is an internal API you could probably just use basic authentication and be done however.Interesting that you're "not always quick to recommend using a framework". Why's that? This is, incidentally, a public API yes. And self-documentation would be a bonus (we currently maintain the docs entirely separately, which is a bit arduous).
Update:
See Adam's comment about documentation in Taffy, below.experience... although I do also use Node, Ruby and Python, just most comfortable with CFML and I don't find any issues making robust REST apps/API's with it...That's food for thought: having experience with those other options but still opting for CFML. Cheers!
Although I personally would use Clojure + FW/1, for a team with CFML / C# skills, using CFML for the new REST API makes sense: it's pretty easy to build a simple REST API in CFML, using Taffy (or FW/1, if you don't want to go full depth into everything REST has to offer), and it's tech the team already mostly knows. Definitely avoid Adobe's horrible REST implementation tho'...Fair point.
I like CFScript because it's syntax is close to that of Javascript, where I also spend a lot of time. I find it quite easy to switch between the two. I would use CFWheels as the framework on which to build an API if I were starting from scratch today.Just to be clear, CFScript is part of CFML. It's not distinct from it.
ASP.NET + Entity Framework makes REST really easy, the team is familiar with C# so s/b smooth.
Existing models etc.This is from a vote for CFML, so indicating we can re-use existing code. That said, I would not be putting any models in my REST layer. That stuff - IMO - should simply deal with translating the HTTP request into a call to relevant business-domain code.
Personally, I'd favor a CF solution, followed up by PHP, then C#, then Python. To me, the language doesn't matter much, provided the API is well designed and documented. Focus on the design, not the language: it was SOAP, now moving to REST - and in 10 years time you'll be building it again in something else.PHP?! Blimey.
use coldbox. then when you have implemented a RESTful API in the language your most familiar with then you are in a better position to say what next?
REST in Railo 4 is stupid-easy .. which is good. http://www.getrailo.org/index.cfm/whats-up/railo-40-released/features/rest-services/ Also, there's Taffy and the BloatBox guys have some stuff. I'd stay w/CFML if the rest of the app is stable and there's no good reason to change platforms. You'll spend some time writing adapters but still better/faster than a rewrite. I'm primarily CFML, however, the python django stuff is where I'd go if I had to choose other.
Since the team has C# experience I think would provide a nice way to build a SOAP service. Visual Studio has a lot of nice tooling to build a SOAP based web service. If you can convert the API to a REST based API you can use Microsoft’s excellent Web API framework.
Short learning curve for ASP.NET MVC developers. Fast scalable and testable.
Possibly some code re-use.(this was in the context of sticking with CFML)
I've done this 3 times within my team and popped in Taffy when we were running CF8 and our migration to 10, was able to reuse all my model components, put the framework in it's own Git container to update. It really took about 5 minutes to setup and then another 10 minutes to get the APIs I needed. Easy peasy.
Use Coldbox for REST though, or Taffy, not the standard CFML implementation. They would very well and easily.
Grails (picked Groovy above) allows for easy customization of url mappings. The resource mapping will set up a controller with methods for all http verbs for instance "/books"(resources:'book') Sets upThat all seems really excellent and easy. Wow.
Want to nest?HTTP Method URI Grails Action GET /books index GET /books/create create POST /books save GET /books/${id} show GET /books/${id}/edit edit PUT /books/${id} update DELETE /books/${id} delete
"/books"(resources:'book') { "/authors"(resources:"author") }
BOOM. resources here refers to the controller.
For getting an object or objects ready to return JSON Marshallers provide maps to, umm, map the data how you want it.
The respond command matches the incoming Content-Type with the correct return format be it json, XML or HTML.
http://grails.org/doc/2.3.10/guide/theWebLayer.html
If you are stuck on anything less then CF11 (or on Railo), look at Adam Tuttle's Taffy. Adobe did clean up REST in 11, but given its "newness" and how botched it was in 10 might not be a choice. Then again it is one of the Adobe marketing bullet points for PHBs. If PHBs are on a kick to remove ColdFusion from the environment go with C# since there are already dev skills there and possibly re-dev the entire app while you are at it.
If your strengths are in CFML and C#, those should be the first two places you look (i.e. use the talent you have). Have you looked at Taffy? The code is really rather straight forward and minimal, and infinitely more debuggable than Adobe's implementation of REST. C# also offers web service functionality, but the last time I looked at it (admittedly long ago) it was piss poor.
You know cfml and taffy makes rest apis easy. Though I'm sure something similar exists for c#, so if your progrative is to learn it, then I'd go with c#.
Personally I'd pick CFML purely because I'm most comfortable with it and I can get started quickly. If I had a big work or team project to do I'd say C#. It saddens me a bit but honestly I feel CFML REST is awkward, to many odd tags that break the web service if they're absent or wrong. It needs to be simple and quick. I've struggled far to much with Python in the past to even consider it. Honestly I'd be surprised if you told me REST was even possible with Python. Groovy and Ruby I'd be curious to try, but I have no idea about hosting / securing these languages on a server.This is a good point that no-one else has touched on. Having the dev willpower to learn a new language is one thing, and I'm fine with us being able to do that. However there's also the consideration that the infrastructure guys need to support it too.
Because node is extremely lightweight, can handle thousands of concurrent connections and it uses JavaScript which is a ubiquitous web language
It holds up to washing nicely, keeps it's color fit is as expected and was well loved when opened.This is one of the more relevant recommendations of C# I've seen ;-)
the nodeness is the greaterest ever
HAPI (https://github.com/spumko/hapi) runs in Node.js and is so far ahead of anything else when it comes to API development that none of the "alternatives" are even worth considering.I need to look at this HAPI thing, as it's had a few mentions here.
If the rest of the codebase is in CFML, I don't see much point in implementing the REST API in another language just for the purpose of doing so. And chances are, if you're going to rewrite the app out of CFML and into something else in the future, the API is going to change. So, I'd stick with the API in CFML.This is quite saddening: "I don't see much point in implementing the REST API in another language just for the purpose of doing so". It kinda shows a lack of aspiration.
Best stable language on the Web nowadays. Small footprint, and out of the box support for restful api's (webapi). Plus, you say you already use it.This is in reference to C#. It kinda made me raise an eyebrow, a bit. I'd like to hear other people's opinions who have used C# and [other web languages]. It's certainly not a position I hear people taking, very often.
some more js experience would probably be a good thing :p(regarding node.js)
- Very fast to get a prototype up (not much code needed + growing ecosystem for most RESTful needs) - Scales well - Dynamic language well suited to process JSON requests (avoiding strong bindings) - Even if just to front heavier services in the blackens that do the heavy lifting(again, re node.js)
Well here's the thing... because REST APIs are fairly simple, I thought it would be a good opportunity to branch out from our comfort zones and use something else.I'd personally choose any language that the team was comfortable with. Writing REST APIs is one of the easier tasks we have to take on - clear specifications and no UIs to feck with you. So just use your most familiar language and concentrate on the spec of the API.
- You're familiar with it
- It has decent tools to get that job done with minimal fuss
I'm a Coldfusion developer for one. Secondly it's all there for you built into CF. Easy.
Of all the languages listed Node.js seems the most interesting, and I'd like to get up to speed with it. So if the decision was mine, this is the direction I'd take. Disclosure: I've not used anything on the list other than CFML beyond "hello world" level, but I'm reasonably proficient at JavaScript.This is my own comment.
Node with Hapi.js is perfect for implementing API's. It's fast. It's lightweight. And it's easy to implement.
It would really be helpful if you could justify why you made your language suggestion. Please provide the rationale for your selectionThey were simply the ones members of the team have expressed interest in. Nothing more or nothing less.
Great feedback everyone. I must say Adam Tuttle's Taffy gets very good press here (is it 16 separate mentions? Nice one). If we go CFML for this job, I'd def be using that.
I have taken on board the many suggestions to stick with where our strengths lie, and that's good advice.
I was surprised there weren't more people suggesting Groovy, and no-one suggested either of Scala or Clojure. Hmm.
The bottom line for me... Node.js does seem very very interesting...
Hopefully more people will have more feedback now that they can see what other people have said (and what I've had to say to them in return).
Cheers for your help, everyone.
(Oh, and make sure you read the comments below! Sean and Mark have some good observations, and hopefully more come in as time passes).
--
Adam
