Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
We are thinking on moving our Rest API Server (it is inside the web service, on Symfony PHP) to Scala for several reasons: speed, no overhead, less CPU, less code, scalability, etc. I didn't know Scala until several days ago but I've been enjoying what I've been learning these days with the Scala book and all the blog posts and questions (it's not so ugly!)
I have the following options:
build the Rest API Server from scratch
use a tiny Scala web framework like Scalatra
use Lift
Some things that I will have to use: HTTP requests, JSON output, MySQL (data), OAuth, Memcache (cache), Logs, File uploads, Stats (maybe Redis).
What would you recommend?
In no particular order:
Akka HTTP
Spray
Paypal squbs (Akka/Spray)
DropWizard
REST.li
http4s
Blue Eyes
Finagle - A fault tolerant, protocol-agnostic RPC system
Play! and Play-mini! (article) (tutorial)
Lift / Lift JSON.- makes it simple to provide REST services.
I'm going to recommend Unfiltered. It's an idiomatic Web framework that does things "the Scala way" and is very beautiful.
Take a look at Xitrum (I'm its author), it provides everything you listed. Its doc is quite extensive. From README:
Xitrum is an async and clustered Scala web framework and web server on top of Netty and Hazelcast:
Annotation is used for URL routes, in the spirit of JAX-RS. You don't have to declare all routes in a single place.
Async, in the spirit of Netty.
Sessions can be stored in cookies or clustered Hazelcast.
In-process and clustered cache, you don't need separate cache servers.
In-process and clustered Comet, you don't need a separate Comet server.
I would add two more options: akka with built-in JAX-RS support, and simply using JAX-RS directly (probably the Jersey implementation). While arguably less "Scala-y" than others (relying upon annotations to bind parameters and paths), JAX-RS is a joy to use, cleanly solving all of the problems of web service coding with minimal footprint. I've not used it via akka, I would anticipate it being excellent there, getting impressive scalability via it's continuation-based implementation.
Take a look at Finch, a Scala combinator library for building Finagle HTTP services. Finch allows you to construct complex HTTP endpoints out of the number of predefined basic blocks. Similarly to parser combinators, Finch endpoints are easy to reuse, compose, test, and reason about.
All good answers so far. One point in Lift's favor is its RestHelper, which can make it quite easy to write short, elegant API methods. In addition, all the other things you want to do should be quite straight-forward to implement in Lift. That being said, Memcache might be not be necessary.
A little late on the scene but I would definitely recommend using Bowler framework for creation of REST API's. It small, to the point and automatic case class conversion support!
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have custom API included in a website which creates new UID on new unique user visit like Google Analytics and sends the UID data to the backend server(NodeJs) for computation.
I need to check concurrent users and max the limit of users can be created/handled per current cloud config.
Also, need to check, is there any limit on API creating and sending users data. The API is on CDN(fastly)
Please suggest some testing tools, to check for above scenario.
SoapUI is a kind of standard for web services functional testing, it has also certain load testing capabilities
Web Services are basically JSON or SOAP over HTTP so any tool which supports HTTP protocol will suit. Here you can find the list of free and open source load testing tools. Narrowed down to the most powerful ones it will look like:
Grinder
Gatling
Apache JMeter
Tsung
Check out Open Source Load Testing Tools: Which One Should You Use? article for the main features comparison, sample scripts and reports.
I agree with Dmitry that those four (Grinder/Gatling/Tsung/Jmeter) are good tools, with a lot of functionality, but they are also fairly complex, require dependencies and can be somewhat painful to get started with. It all depends on your requirements which tool is best for you.
It sounds to me like you want to test one or two REST API end points powered by NodeJS. If you want a simple-to-get-started with tool that can be scripted, there are some good command-line tools available:
Wrk - very fast, scriptable in Lua
Artillery - NodeJS-based, scriptable in JS
k6 - our own newly released tool, currently the fastest tool scriptable in JS
There is also Locust which is scriptable in Python, but very low-performing.
I like these tools because they offer simple command-line usage and can be scripted in a real language, as opposed to Jmeter and Tsung, where you'll have to resort to XML if you want to do something slightly out of the ordinary. Gatling is a bit better, offering a DSL based on Scala classes where you can do most things but it is still not "real" Scala. The Grinder is the only one of those other tools that offers true scripting (in Jython), but again, it is not a simple one-line command to get started.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have an ASP.NET MVC 4 project and I'm stuck on an architectural decision on which JavaScript framework or library to use Angular.js or Knock.js. I am currently leaning towards using Angular.js over Knockout.js, but don't want to find out midway during project development I made a mistake.
Here is some background:
We need two-way model data binding
We need the ability to test views. I want to be able to do end to end unit testing. Also, we are using continuous integration.
"Save Changes" functionality. i.e. if a user makes changes on a page we need the ability to detect any changes and prompt the user to save their changes before they navigate away from the page
"Notifications" functionality. i.e. user will be logged on approximately 8 hours and will need to be notified and updated of changes made by other users (errors, data status changes and the like)
We need to "future proof" our application. Currently the business unit hasn't decided if we will need to support mobile devices, but I know it's just a matter of time.
Our team consists of developers with varying experience levels from very junior to senior developers.
Currently our models are complicated and may get even more so
We need to also consider RAD, code reuse, and maintainability
I have read the excellent answer here and watched Scott Allen's interview about Angular here
Since we are unable to change from our current ASP.NET MVC 4 architecture to use something on the server side like Web API I have some concerns in trying to implement Angular.js with MVC 4. Will this cause us to have two models one on the server and one on the client?
I am not looking for a "which is better" discussion about Angular and Knockout because I think they both have their pros and cons. I am looking for actual code on implementing a JavaScript framework or library in an ASP.NET MVC 4 application. I need a solution that I can live with 2+ years from now :)
Any ideas or suggestions? Maybe the answer is not Knock or Angular, but some other JavaScript framework?
my 2 cents worth.
preamble - i have worked with both angular and knockout.
I'm on my 3rd non trivial front end built with a MVVM/MVC lib.
I started with knockout because its MVVM is very similar to the wpf/silverlight mechanics. And it works well. The tutorials and documentation are top notch. All your coders will be able to work with knockout.js within days or if they have used mvvm under .net, then within hours.
However, these days I am using angular and will probably stick with it for the following reasons.
angular is a complete framework - knockout is really about just the 2
way binding. you still need other libraries like backbone.js/jquery
to do the rest of your work.
angular has dependency injection. which is perfect for adding
mocking for testing as well as giving structure to your code.
angular treats normal JS variables as observables within its $scope
object. that means you dont have to declare them in a special way
I'm not an angular fanboy, i still think they could move more over to the MVVM architecture instead of the "funky" MVVM/MVC hybrid architecture they currently have.
The biggest problem with angular is the documentation. Compared to knockout, it is woeful. It will add additional time and cost to getting your coders up to speed. Once they are there however, it is currently the best choice IMHO.
Glad to see this questions was of interest to the community ;) Just for completeness here's what I ended up doing:
I did go with AngularJS and ASP.NET MVC 4 and was glad that I did. Although, Angular has a steep learning curve but its worth it because of the power of directives.
We need two-way model data binding - On occassion I needed to set some initial values coming from the MVC controller. I used the ng-init attribute to accomplish this.
We need the ability to test views - I followed the AngularJS docs for testing
"Save Changes" functionality - I implemented this using a directive in Angular
"Notifications" functionality - I implemented this using toastr.js and and directives (schweet)
We need to "future proof" our application - I don't know Google's plans for AngularJS, but after working with AngularJS I can't see it going anywhere anytime soon and expected it to become more widely adopted :)
I don't have a lot of input on AngularJs, but want to provide some thoughts on Knockout.
Knockout is primarily a data-binding library to connect views to view model, but doesn't really provide a lot of capabilities beyond that. I wouldn't recommend using knockout alone as the main library to build a complex client-based web site.
You didn't mention whether you're implementing spa-like functionality (i.e. hash-tag navigation) or whether you're primarily using MVC server-side views (e.g. Razor). If you're just looking for quick data-binding on a per-page level, I would even reconsider that. To me, both of these (angular or knockout) are designed to enhance the client-side development experience - not so much a server-side approach such as MVC.
If you're considering an SPA approach, even in part, you'll likely want some framework that provides some level of control over the view activation life cycle.
As far as data-binding power and reliability, I believe in Knockout. I have been using it extensively, and have grown quite fond of it. If you like the feel of knockout, you may want to look into Durandal. Durandal is a decent framework is able to meet the needs of many "spa" web projects. It's a client-side framework built on top of several proven libraries, including Knockout. It's a little (lot) more light-weight than Angular, and possibly easier to user.
We are building a fairly large ASP.Net MVC web site using Durandal with Knockout in conjunction with an additional facade to tighten things up from a development standpoint, and the integration with ASP.Net MVC is straight-forward. I don't recommend trying to use the server-side knockout stuff that's out there; I just find that to limit the real power of the MVVM pattern.
I am planning to build a web service for providing JSON/XML data to client via HTTP. And I am planning to make it RESTful, but this is only a best-to-have option rather than a must. And normally, I will host it in IIS.
To achieve this, by my analysis, I have 3 options (I need to use MS technologies): WCF service, WCF Data Service and MVC4 WebAPI. I still have one more question before making the final decision. Yes, there are a lot discussions on web talking when to choose one of them, but they focus on other topics such as Protocol, easy to implement, leverage HTTP etc etc.
However, my focus is on the other aspect: from performance aspect, what is the best one (suppose I correctly use them) from the 3 options (to provide JSON/XML via HTTP)?
Frankly there is no definitive answer to your question, it all depends on what kind of traffic are you expecting (or wanting to serve), what kind of functionality would your REST api have (which also impacts performance), and lots more.
Rick Stahl has created a nice blogpost about this. http://www.west-wind.com/weblog/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance
Its not the final answer to your question (namely what is the best). But it should give you some better perspective and hopefully a better position to answer your question.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I try to be very cautious with this question. There are at least three different web-development frameworks available in Smalltalk. The most prominent seems to be Seaside but there is also AIDA/Web and Iliad.
They seem to be very similiar, but this impresson may be wrong. I wonder who has tried the different tools and can share the pros/cons of the different packages.
A more concrete question would be, do yo know of let's say any software in the bookkeeing area which has choosen to use either of the three (or other) web development frameworks.
Here's one other question. What about maturity and compatiblity. Which framework can one judge as the "most" stable?
99% of my practical experience is with Iliad, so my comparison is primarily about how I got to choose Iliad instead of the others.
Seaside. Tried it first, it is the most known and the first you stumble in. I found it hard to understand (as always, no matter what you use, when it gets to real implementation you always run into issues that fit badly with the general theory), there was little documentation around and the community seemed to care little about telling n00bs how to grow up. I eventually dropped it to check Aida. You find them here: http://seaside.st/ and on IRC at #seaside
Aida. I really liked it, as Janko is extremely patient and supportive. It is large, though. I decided to use it, when I was to start implementation for our project and it was only by chance that I ran into Iliad a few days before starting. You find Aida here: http://www.aidaweb.si/ and on IRC at #Aida
Iliad. The main reason I chose it was that I had just dropped Squeak and switched to gnu-smalltalk. gst seemed to have a lot of ongoing activity on Iliad, so I reckoned I was probably going to get a better assistance with it. It is much smaller as a concept (though it does absolutely everything) and I had very little trouble in getting started and in tweaking it to what I needed for. It also proved to be well managed, as I went thru 3 releases without ever being in trouble with what I had already deployed. You get answers to questions usually in 12-24 hours max, which is fine for me. You find Iliad here: http://www.iliadproject.org/index on IRC issues are usually channeled on the #gnu-smalltalk channel
What we are doing is a GUI for a PostgreSQL database used to manage a large multimedia dictionary, that in turn produces content (among others, for KDE-edu). I have no notion of booking apps in general, so I cannot answer to your question properly.
Yet, speaking as an analyst, a booking app is mostly a DB with an online GUI, so I see no reason why you could not make it. Much will depend on how easily your db can translate into objects. You could use a RDBMS, as we did, and design tables to map objects, or use an OODBMS. Both solutions have pluses and minuses, none of them is going to have an impact on your choice of framework, I'd say.
My suggestion is that you take a month or so in making experiments and see what better fits you. I don't think there is a tool that fits everyone, we are all different and what is easy for me may be hell for someone else (and the other way round, obviously). So try your car before buying it ;)
I would not invest too much time in studying the general theory. Using a smalltalk framework is going to turn upside down the way you make a web app anyway, and your first contact is going to be full of "false friends" you inherit from previous mindsets. Your best asset is definitely going to be "how quick can I grasp what they tell me", and this is largely an individual thing, depending on you and on who you bump into. So I'd really suggest you get your hands dirty BEFORE reading too much theoretical stuff.
These frameworks are all quite different and have different goals. It would be interesting to collaboratively create some kind of comparison.
As an author of Seaside I can provide the key properties of Seaside only:
Seaside makes building web applications feel like composing traditional GUIs: components can be freely composed and reused. Sequences of components are defined using a sequence of Smalltalk statements.
Seaside has a layered architecture, providing you with high-level abstractions (components, control flow, callbacks, HTML generation, JavaScript generation, ...) over low-level concepts (HTTP, Request, Response, URLs, HTML, JavaScript). If you need to, Seaside gives you full access to low-level constructs too.
There are two Seaside books to help you get started: Dynamic Web Development with Seaside and Seaside Tutorial.
Seaside provides a tight integration into various state of the art web technologies: JavaScript (JQuery and JQueryUI), SVG, RSS, HTML5, Comet (Server-Push)
Seaside runs identically on most today's Smalltalk platforms: Pharo Smalltalk, Squeak, GNU Smalltalk, GemStone Smalltalk, VW Smalltalk, VA Smalltalk, and Dolphin Smalltalk. It is supported by all vendors of Smalltalk platforms.
Seaside provides industry proven open-source components for meta-modeling (Magritte) and content management (Pier).
Let me introduce some strengths of Aida/Web too, because as its author it would be hard to me to compare with other two frameworks. Aida strengths are:
RESTfull URLs
MVC support, every domain object can
have its own RESTfull URL, each domain class has its own web presentation class,
Integrated AJAX and Comet
support, you don't see any difference
between a traditional and Ajax
programming anymore,
Tree-like control flow for GUI-like
control flows, without need for
continuations
Building web pages programatically by
composing from components/elements
(no template based)
Scalable in complexity and performance
Integrated security with access
control and users/groups management
Ported to most Smalltalk dialects:
Squeak/Pharo, VisualWorks, Gemstone
GLASS, Dolphin, Smalltalk/X
Prime and most fresh example of Aida at work is this year Smalltalk Google Summer of
Code site.
This is the is a nice example because it was developed it in maybe a week in
total, together with a development of GSoC process in parallel and in
the same time managing that process as an admin. This site is actually
an extended Aida/Scribo CMS, with strong use of so called scriblets,
that is, dynamic web "includes" directly into the content of the site.
That way I was able to very quickly support the new ideas which come
during the evolving GSoC process.
Well, Suixo uses Seaside. Take a look at the GSoC projects we defined. Its more ERP than bookkeeping, and currently focused on healthcare.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am planning on putting up a web service, or some other service exposed over the internet. I would like to create an API for applications to interact with this service. I would like the API to be usable in different languages, such as Java, C++, C#, or PHP. How can I maintain one code base for my API, but distribute nice packaged binaries for all these languages? Also, I may want to consider this could be cross platform as well.
Update 1
I'm early days on Web Services, but I
think one of the key points is that
lots of tooling supports the
implementation of clients based on the
description of the service like WDSL.
I've not delivered any client-side
software with anything I've done, I
expect any user to be able to build
their own clients suited to their
needs. --Brabster's Answer
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
Update 2
As far as expecting the client that is
using your API to do anything, you
can't! There is nothing you will be
able to do to ensure that the consumer
of the API will do anything right.
That's why robust error handling is so
important. You must check and double
check any and everything that comes
from the client. You must always be
suspicious of it, and even assume that
it is malicious. There really is no
good way around that fact. --Ryan Guill's Answer
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
Update 3
I have accepted Ryan Guill's answer. I think the general idea is that I need to expose a network service of some sort, with the lowest barrier to the client. That way anyone can connect. Then just have all my code run on the server. That seems to be accepted as the only want to really achieve the platform and language independence I am after.
Thanks for all the input.
I would use a REST API, similar to the way Flickr's API works: http://flickr.com/services/api/
It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.
But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.
More information here: http://www.xfront.com/REST-Web-Services.html
Update: The submitter added the following to the post:
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API.
Some more examples of public API's written using REST: twitter, vimeo, Google
As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.
Update 2: the submitter added the following to the post:
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.
But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator.
I'm early days on Web Services, but I think one of the key points is that lots of tooling supports the implementation of clients based on the description of the service like WDSL.
I've not delivered any client-side software with anything I've done, I expect any user to be able to build their own clients suited to their needs.
If you check out the flickr API as suggested by one of your other answers, I don't think they supply client side code, other people have built and contributed client side stuff.
I suggest writing the API in the Haxe programming language so that the source code can be directly translated to all the programming languages you mentioned. The Haxe programming language can be translated (or "trans-compiled") to all of the programming languages that you mentioned in the original post, as well as a few others.
Simple answer, no.
Complex answer: create an API and compile it to a COM dll. Then, just build the wrapper code for the languages that can't handle that.
Simple answer #2, make the original service so trivial, or so universally acceptable, as to not require an API (I usually implemented this through server-side database polling. Ugly but any language that can access a database can utilize the program).